Tem dia em que o expediente acaba, o Slack fecha, o notebook fecha e, ainda assim, o trabalho não terminou de verdade.
Ele só mudou de lugar.
Foi esse o eixo de um relato recente publicado no Dev.to que bateu em cheio numa dor bem conhecida de quem trabalha com desenvolvimento: a hora extra que não aparece no ponto. Segundo o autor, o problema não era exatamente estar codando até tarde todos os dias. Era perceber que o trabalho continuava rodando em segundo plano no jantar, na cama, no sábado de manhã e naquele impulso clássico de “vou só checar uma coisinha”.
O valor do caso não está no drama. Está na precisão. Porque muita gente em TI ainda mede desgaste só por hora sentada na frente da tela — e perde um pedaço importante da conta: o expediente mental invisível.
o problema não é só trabalhar até tarde
No relato, o autor descreve uma cena banal demais para parecer séria: bug aberto no fim da tarde, notebook fechado, cabeça ainda tentando resolver a causa do problema horas depois.
Segundo ele, isso volta de vários jeitos. Às vezes como pensamento repetido sobre uma função mal refatorada. Às vezes como vontade de abrir o Slack “rapidinho”. Às vezes como aquele sábado que era para ser livre e vira mini sprint de side project sem ninguém ter pedido.
A leitura mais útil aqui é esta: nem toda sobrecarga vem em formato de plantão, incidente ou jornada oficialmente estendida. Parte dela vem na incapacidade de desligar.
E isso pesa porque, em software, muita coisa termina sem sensação real de término. PR aprovada com dúvida, teste falhando sem causa clara, decisão de arquitetura meio torta, ticket que ficou pela metade. O relógio encerra o dia, mas o cérebro continua tentando fechar pendência aberta.
por que isso pega tão fácil em desenvolvimento
O próprio texto acerta quando diz que isso não parece só um problema de disciplina pessoal.
Em muito trabalho, existe um ponto natural de parada. Em desenvolvimento, esse ponto é mais nebuloso. O sistema continua quebrado. A hipótese ainda não foi testada. A tarefa não ficou exatamente pronta. A dúvida não morreu sozinha.
É aí que começa a armadilha.
Você não sente que escolheu continuar trabalhando. Sente que ainda não conseguiu sair do problema.
Esse detalhe faz diferença porque muda o diagnóstico. Não é apenas “falta de equilíbrio” no sentido genérico. É um tipo de trabalho que deixa loops abertos demais na cabeça de quem vive apagando ambiguidade, erro e incerteza o dia inteiro.
a hora extra mais cara é a que ninguém conta
Tem um trecho do relato que ajuda a dar nome ao que muita gente normaliza: parte da sobrecarga não acontece na mesa. Ela acontece no banho, no treino, no jantar, antes de dormir.
Não vai para planilha. Não vira banco de horas. Não entra em reunião de retrospectiva.
Mas cobra.
Isso conversa com outra fonte lida nesta rodada, também no Dev.to, em que um desenvolvedor descreve burnout, recuperação lenta e uma percepção incômoda sobre a área: coding cansa mentalmente, layoffs rondam o mercado, cerimônias engolem autonomia e ainda existe a pressão silenciosa para continuar “provando paixão” fora do expediente.
Nem todo pensamento sobre código à noite é sinal de burnout, claro. Às vezes uma boa ideia aparece no banho e tudo bem. O problema começa quando parar deixa de ser escolha.
o gatilho mais comum vem disfarçado de responsabilidade
Quase todo dev conhece esse roteiro:
- “vou só ver se responderam aquele PR”
- “vou só abrir o Slack um minuto”
- “vou só testar uma hipótese antes de esquecer”
Na prática, o que era um fechamento vira continuação. E o mais traiçoeiro é que isso costuma parecer comprometimento, não vazamento.
Só que empresa nenhuma precisa dizer explicitamente “fique online para sempre” para o efeito acontecer. Basta um ambiente cheio de pendência ambígua, urgência difusa e pouca fronteira de encerramento.
Por isso esse caso é melhor do que muita discussão genérica sobre produtividade. Ele mostra que a conta não explode só quando alguém trabalha 14 horas por dia. Às vezes ela se acumula em blocos menores, invisíveis e socialmente elogiáveis.
a saída prática do caso é menos glamourosa do que parece
O ponto mais útil do relato não é uma teoria. É um ritual simples de desligamento.
Antes de fechar o notebook, o autor sugere registrar o que ficou em aberto, o que já se sabe sobre aquilo e qual é a próxima ação específica do dia seguinte. Não “resolver bug”, mas algo como “validar por que o retry handler roda duas vezes” ou “confirmar se o cache invalida antes da resposta terminar”.
Parece pequeno, mas faz sentido.
Quando a pendência fica só na cabeça, o cérebro trata aquilo como problema ainda sem lugar para repousar. Quando você externaliza o estado atual e o próximo passo, a chance de continuar carregando a tarefa no modo ruminante cai bastante.
Em português claro: seu cérebro não é board de tarefa.
o recado maior para quem trabalha com TI
Esse community-case não diz que todo dev está a um passo do burnout nem que pensar em código fora do expediente virou crime. O que ele diz é mais útil do que isso.
Diz que a área criou uma versão muito normalizada de sobrecarga invisível.
E que talvez uma das habilidades mais subestimadas de 2026 não seja “aguentar pressão”, e sim saber estacionar problema inacabado sem levar o expediente inteiro para dentro da noite.
Segundo o relato, fechar o notebook não basta sempre. Em muitos dias, sair do trabalho precisa virar uma ação deliberada.
Porque, se o bug continua morando na cabeça até a hora de dormir, o expediente já passou do horário faz tempo.
