- Segundo pesquisas de psicologia cognitiva, o limite de trabalho profundo (deep work) do ser humano é de 3 a 4 horas por dia; depois disso, a concentração e a qualidade do código caem rapidamente
- A análise de mais de 250 mil desenvolvedores mostra que o tempo mediano real de programação é de apenas 52 minutos por dia, e o restante é consumido por reuniões, gestão e colaboração
- Após uma interrupção, leva-se 23 minutos para voltar à tarefa original e, no caso de programadores, 30 a 45 minutos para recuperar todo o contexto
- No estado de flow, a produtividade aumenta 500%, mas são necessários de 15 a 25 minutos contínuos de concentração para entrar nele
- O papel do engineering manager não deve ser adicionar processos, e sim remover distrações e proteger o tempo de trabalho profundo
Limites cognitivos: 4 horas por dia é o teto do trabalho profundo
- Cal Newport define trabalho profundo como "atividades profissionais realizadas em estado de concentração sem distrações, levadas até o limite da capacidade cognitiva", e para a maioria das pessoas a média máxima é de 4 horas por dia
- O estudo de K. Anders Ericsson com violinistas também confirmou que a fadiga aparece após 4 horas de prática concentrada
- Desenvolvimento de software também é trabalho cognitivo de alta intensidade, com resolução criativa de problemas e design de sistemas, então após 3 a 4 horas há retorno decrescente
- O matemático Henri Poincaré trabalhava 2 horas pela manhã e 2 à tarde; G.H. Hardy trabalhava apenas de manhã; Charles Darwin, B.F. Skinner e C.S. Lewis também mantinham rotinas de 3 a 4 horas de trabalho
- Segundo pesquisa de Gloria Mark, da UC Irvine, o tempo médio atual de foco na tela é de 47 segundos, uma queda acentuada em relação aos 2,5 minutos de 2004
Como os desenvolvedores realmente usam o tempo
- A análise da Software.com com mais de 250 mil desenvolvedores mostrou que o tempo mediano de programação é de 52 minutos por dia (cerca de 4 horas e 21 minutos por semana)
- Apenas 10% dos desenvolvedores programam mais de 2 horas por dia, e 40% programam mais de 1 hora
- Segundo a análise de 1,5 milhão de reuniões da Clockwise, engenheiros de software passam em média 10,9 horas por semana em reuniões
- Engineering managers passam 18 horas por semana em reuniões, quase metade de uma jornada de 40 horas
- Desenvolvedores em organizações grandes gastam 12,2 horas por semana em reuniões; em organizações pequenas, 9,7 horas
- Excluindo reuniões, gestão, code review e colaboração, restam 19,6 horas semanais potencialmente focáveis, mas em sua maioria fragmentadas em blocos curtos e pouco úteis
- 45% de toda a programação acontece entre 14h e 17h, enquanto entre 9h e 11h ocorre apenas 10%
- Não porque desenvolvedores sejam naturalmente vespertinos, mas porque as manhãs são tomadas por standups, syncs e cerimônias
O alto custo das interrupções
- Segundo pesquisa de Gloria Mark, após uma interrupção leva-se exatamente 23 minutos e 15 segundos para retornar completamente ao trabalho original
- Em estudo do Georgia Institute of Technology, programadores levavam de 10 a 15 minutos para retomar a edição de código e 30 a 45 minutos para reconstruir todo o contexto mental
- No ensaio "Maker's Schedule", Paul Graham argumenta que reuniões não são apenas troca de tarefa, mas uma exceção (
exception) que muda o próprio modo de trabalho
- Uma única reunião pode destruir a tarde inteira, e só o fato de haver uma reunião marcada à tarde já desestimula começar um trabalho ambicioso pela manhã
Estado de flow: o multiplicador de produtividade dos programadores
- Mihaly Csikszentmihalyi define o estado de flow como "um estado em que a pessoa fica totalmente imersa na atividade, o senso de eu desaparece e a noção do tempo se perde"
- Após 10 anos de pesquisa, foi confirmado um aumento de 500% na produtividade em estado de flow em comparação ao estado normal
- A chave para entrar em flow é o equilíbrio entre desafio e nível de habilidade; desafio demais ou de menos atrapalha o flow
- Em equipes de software, times que vivenciam flow com frequência entregam mais valor, mais rápido e com maior satisfação
- Flow não surge naturalmente; é essencial protegê-lo dos fatores que o drenam
Como entrar em flow durante a programação
- Criar um ambiente sem interrupções: fechar o Slack, silenciar notificações e usar indicadores visuais de status para sinalizar modo de trabalho profundo
- Mesmo sem responder às notificações, apenas vê-las já reduz a concentração
- Definir objetivos claros antes da sessão de programação: em vez de "trabalho de backend", definir algo específico como "corrigir o endpoint de autenticação para retornar respostas de erro adequadas"
- Resolver problemas difíceis no pico cognitivo: pesquisas sobre ritmo circadiano mostram que o desempenho cognitivo varia de 9% a 40% conforme o horário
- Para a maioria dos adultos, o melhor horário para resolução de problemas vai de 10h a 14h
- Pessoas matutinas ("cotovias") e noturnas ("corujas") têm picos diferentes, então é preciso proteger o horário de pico individual
- Time blocking para a maker's schedule: reservar no calendário blocos de 2 a 4 horas de trabalho profundo e concentrar reuniões no fim do dia ou em dias específicos
- Definir um objetivo para cada bloco e quebrá-lo em três tarefas executáveis
- Eliminar trocas de contexto: em vez de responder imediatamente, criar duas janelas de comunicação por dia e fechar abas do navegador que não tenham relação com a tarefa atual
- Trabalhar em sessões concentradas, não em maratonas de sprint: pomodoros de 25 minutos não são adequados para trabalho complexo de desenvolvimento, porque o timer interrompe justamente quando o flow começa a surgir
- O objetivo não é o maior tempo possível, mas a maior qualidade dentro do limite da capacidade cognitiva
- O efeito composto da reflexão e do aprendizado: nos estudos de prática deliberada de Ericsson, o que gera expertise não é o tempo bruto de trabalho, mas o pensamento reflexivo
As 4 estratégias de trabalho profundo de Cal Newport
- Estratégia monástica (Monastic): eliminar completamente o trabalho superficial
- O caso clássico é Donald Knuth, que aboliu o email em 1990
- Estratégia bimodal (Bimodal): separar a semana entre dias de trabalho profundo e dias de trabalho superficial
- Exemplo: indisponível de segunda a quarta; reuniões e emails na quinta e sexta
- Estratégia rítmica (Rhythmic): fazer trabalho profundo sempre no mesmo horário, sem exceções
- A abordagem "não quebre a corrente" de Jerry Seinfeld
- Estratégia jornalística (Journalistic): entrar imediatamente em trabalho profundo sempre que surgir tempo livre
- Pode funcionar até em blocos de 30 a 45 minutos, mas há o risco de confundir troca de contexto com trabalho profundo de verdade
- Para a maioria dos desenvolvedores, a estratégia rítmica é a mais eficaz; o ponto central é proteger a manhã para programar sem cair na tentação reativa do Slack
Por que engineering managers devem se importar
- Se o tempo real de programação por dia é de 52 minutos, e uma única interrupção consome mais de 23 minutos de recuperação, então uma única mensagem pode gastar quase metade da cota diária de programação
- Experimento da TechSmith: ao eliminar completamente reuniões, houve aumento percebido de 15% na produtividade, e 85% dos funcionários responderam que substituiriam reuniões por comunicação assíncrona
- Em pesquisa da Microsoft com 31 mil pessoas, reuniões ineficientes foram o principal fator de queda de produtividade no trabalho
- Recomendações para managers:
- Garantir manhãs sem interrupções
- Introduzir no-meeting day (por exemplo, quarta-feira)
- Definir comunicação assíncrona como padrão em vez de síncrona
- Estabelecer prazos realistas que permitam espaço para exploração criativa
- Métricas para medir efeito: redução do cycle time, satisfação do time, pontuações de engajamento, taxa de bugs e retrabalho, entre outras métricas de qualidade
Conclusão
- Programação profunda por 3 a 4 horas por dia não é questão de hábito, mas limite físico da carga cognitiva
- O essencial é otimizar os fatores controláveis, como desligar notificações, avisar o time que as respostas virão à tarde e negociar a proibição de reuniões pela manhã duas vezes por semana
- 4 horas de trabalho profundo sempre geram resultados melhores do que 8 horas de "meia concentração"
- Entrar em flow por algumas horas por dia leva a código de alta qualidade, menor risco de bugs, soluções inovadoras e melhor equilíbrio entre vida pessoal e trabalho
- Programadores não são sprinters, e sim corredores de maratona; é preciso preservar energia
Observação sobre assistentes de IA para programação
- Ferramentas como Copilot, Cursor e Claude não estendem o tempo de trabalho profundo; elas apenas deslocam o foco
- Em vez de escrever código do zero, revisar a saída da IA ainda exige o mesmo contexto, julgamento e concentração
- O limite de 3 a 4 horas não é de velocidade de digitação, e sim do quanto o cérebro consegue sustentar decisões de alta qualidade, então ele não muda só porque o código aparece mais rápido
- Onde a IA realmente ajuda é nas horas superficiais (shallow hours): rascunho de documentação, geração de boilerplate, dúvidas sobre uso de bibliotecas etc.
- Ao delegar essas tarefas à IA, é possível preservar o orçamento de trabalho profundo para pensamento arquitetural e resolução de problemas complexos
- A armadilha é usar IA para produzir mais código do que se consegue processar mentalmente
- O objetivo não é gerar mais linhas de código por dia, mas concentrar os recursos cognitivos limitados nas decisões mais importantes
13 comentários
O próprio grupo de comparação está errado.
O estudo com violinistas de K. Anders Ericsson não foi feito tendo pessoas altamente proficientes como referência, mas sim a prática como critério de análise. No caso de instrumentos, mesmo que se pratique uma peça perfeitamente, isso não garante sempre uma execução perfeita (há variáveis a cada apresentação). Já no caso do desenvolvimento, as necessidades são claras e, depois de concluído, o resultado é sempre o mesmo. Há uma diferença muito grande entre fazer continuamente algo que tem fim e fazer continuamente algo que não tem fim. Portanto, definir por si só que a capacidade cognitiva humana é, em média, de 3 a 4 horas também ignora que existe outra diferença entre desenvolver por 3 a 4 horas por instrução de terceiros e desenvolver voluntariamente por 3 a 4 horas. Este texto me parece generalizar tudo para convencer de forma plausível que 3 a 4 horas é o limite da capacidade cognitiva humana. O fato de a concentração deles durar de 3 a 4 horas não significa que a de todos também dure de 3 a 4 horas. Pelo contrário, parece mais um texto que estabelece esse limite e propõe uma espécie de conluio do tipo “vamos trabalhar só 3 a 4 horas por dia”.
Exato~! Na prática, realmente há muitas pessoas que trabalham muito bem.
Espero que as pessoas não se definam dizendo “eu sou assim” com base no auge de concentração e desempenho da própria carreira. Este texto trata o deep work como um estado ideal de trabalho e se esforça demais para entrar nele. Naturalmente, quando aparecem ideias interessantes para resolver um problema e uma direção de tentativa, o deep work surge e a produtividade melhora. Mas, se isso não aparece e a pessoa continua vivendo insatisfeita, acreditando que “na verdade meu cérebro é mais genial do que isso”, no fim ela só reduz muito mais a própria chance de entrar em flow. Quanto menor a metacognição, mais fácil é pensar que meu cérebro é simplesmente “meu”, mas essa condição mental nunca é criada sozinha. É preciso reconhecer a ajuda do entorno que tornou possível chegar a esse nível de concentração — não só por te deixarem em paz ou te darem dinheiro, mas também por te fornecerem vários estímulos, que em algum momento acabam se conectando de forma refinada numa mesma direção; esse é o estado de concentração. Independentemente do resultado, sentir gratidão por dentro, e mesmo sem precisar expressá-la aos outros, manter por si mesmo um nível adequado de satisfação e uma atitude positiva em relação a si ajuda a elevar, no longo prazo, a concentração e a condição mental.
Trabalho em uma empresa em que trabalhamos 3 horas de manhã, almoçamos e depois trabalhamos mais 3 horas à tarde (total de 7 horas, 4 dias por semana). Mesmo só isso já é muito mais confortável mentalmente.
É uma boa empresa!
A razão pela qual, quando todo mundo vai embora do trabalho e não há ninguém por perto, eu conseguia programar sozinho tão bem era essa...;;;
Por isso, quando as outras pessoas fazem hora extra, eu acabo indo embora mais cedo.
Acho que dá para aumentar um pouco com treino, descanso e um ambiente adequado, mas isso acaba moendo a pessoa, então é difícil aguentar por muito tempo. As empresas forçam para extrair isso e abafam o assunto, mas também vejo com frequência técnicos trabalhando à base de remédios (antidepressivos, remédios para TDAH).
Isso mesmo, o fato incômodo é que as clínicas de psiquiatria em Pangyo vão muito bem.
Acho que uma hora por dia de programação já é suficiente. Mesmo antes da IA, o tempo realmente gasto programando já não era tão grande, e agora diminuiu ainda mais.
Quando se trata de desenvolvimento, jogos ou leitura que "eu quero fazer", parece que dá para manter o foco por horas, até terminar a tarefa em questão.
Talvez essas 4 horas se refiram à capacidade de concentração em trabalhos que "você não quer fazer, mas faz porque é sua profissão" (talvez uma espécie de concentração passiva?).
Simples. Qualquer homem provavelmente já teve a experiência de conseguir manter a concentração a noite inteira enquanto joga.
Pela minha experiência pessoal, quando estou fazendo o desenvolvimento que eu realmente quero fazer, mesmo que eu fique várias horas seguidas nisso, não sinto exatamente que fico cansado.
O próprio ato de rodar múltiplas sessões acaba se tornando multitarefa, o que também pode reduzir a concentração.