Você vai se agradecer na manhã seguinte quando puder começar a trabalhar imediatamente em vez de gastar 30 minutos tentando lembrar onde parou. Produtividade não é só sobre velocidade. É sobre continuidade.

- Pare enquanto está indo bem
- Anote exatamente quais devem ser as próximas 3 linhas de código
- Feche o laptop

Parece estranho parar quando está no fluxo. Somos ensinados a perseverar. Mas deixar uma tarefa um pouco inacabada cria um gancho mental (os psicólogos chamam isso de efeito Zeigarnik). Isso mantém o contexto vivo no seu processamento de fundo.

Da próxima vez que estiver avançando em um recurso:

Mas se você parar no meio de um recurso (ou melhor ainda, com um teste falhando que você sabe como corrigir), seu cérebro já está pronto para retomar logo.

Ernest Hemingway tinha uma regra simples: pare de escrever quando ainda souber o que vem depois. A lógica é simples. Se você gastar toda sua energia hoje, começar amanhã significa encarar uma página em branco (ou um IDE vazio) sem nenhum impulso. O "início a frio" é complicado.

Existe um conceito chamado "Efeito Hemingway" que mudou como gerencio minhas sessões de programação, especialmente como desenvolvedor solo nos meus projetos pessoais e como Engenheiro de Software Sênior em tempo integral.

Senão, você acaba com:
• Arquitetura linda
• Tudo em tempo real
• 0 usuários
• Um app que nunca vê a luz do dia

A regra que sigo agora:
Se não ajudar a lançar, não vai ser implementado.

Meu lado gerente de produto (depois de perder 6 horas): "É só um título de filme, não o preço de uma ação. Um fluxo semanal no GitHub já resolve."

Quando você não tem um gerente de produto, precisa ser um de forma implacável.

Meu lado engenheiro: "Precisamos de sincronização diária para todos os títulos. Se um título mudar, o armazenamento vetorial precisa ser atualizado na hora."

It had simply flipped the assertion from true to false. 🤣

Technically, it did what I asked. The test passed. But the code was just as broken as before.

It’s a good reminder: Trust, but verify every commit.

Boa engenharia também é saber quando um problema foi resolvido de forma melhor por outras ferramentas. 🥂

Muitas vezes, ficamos apegados ao nosso código. Queremos que ele continue vivo. Mas arquivar foi um alívio. Mostrou como as coisas mudaram desde que comecei.

Ela serviu bem por muito tempo. Mas em janeiro, percebi que era hora de parar.

O motivo é simples: IA.

O que antes precisava de lógica complicada de scraping e manutenção constante agora é fácil para um LLM. A tecnologia avançou tanto que minha solução não era mais a mais adequada.

Criei essa biblioteca faz tempo porque estava curioso sobre como as coisas funcionavam por trás das cenas. Queria fazer algo parecido com a pré-visualização de links do Facebook, então decidi entender a lógica e criar o analisador por conta própria.

Quando atinjo esse padrão mínimo, me dou permissão para parar. Qualquer coisa além é lucro.

Precisamos de uma "Definição de Concluído" para nosso dia, não só para os tickets do Jira.

A consistência traz resultados mais rápido do que esforços heroicos de vez em quando.

Isso muda o foco da intensidade para a consistência:

- Aprender algo novo: 30 minutos de estudo focado, não uma maratona de 4 horas.
- Projetos paralelos: Entregar um pequeno componente, sem tentar limpar todo o backlog.
- Refatoração: Limpar uma classe, não o módulo inteiro.