Por Que Devs Bons Pedem Demissão (E O Que Empresas Erram)
O melhor dev do time acabou de mandar carta de demissão. Ninguém viu chegar. Mas dava pra ver sim — se alguém tivesse prestado atenção. Os 5 motivos
Por que isso é importante
Resposta direta: em “Por Que Devs Bons Pedem Demissão (E O Que Empresas Erram)”, meça no seu contexto — hype e ranking não substituem eval e aceite.
O melhor dev da equipe saiu. De novo.
Por Que Devs Bons Pedem Demissão (E O Que Empresas Erram). O melhor dev do time acabou de mandar carta de demissão. Ninguém viu chegar. Mas dava pra ver sim — se alguém tivesse prestado atenção. Os 5 motivos reais, sem eufemismo de RH.
Os 5 motivos reais — sem eufemismo de RH
TL;DR: Devs bons saem por crescimento estagnado, gestão que ignora expertise técnica, dívida técnica sem plano, salário defasado e ambiente tóxico normalizado — nessa ordem. Salário é o motivo mais fácil de corrigir, mas raramente é o real gatilho. Quando o dev já tem uma proposta na mão pra negociar, na maioria dos casos já decidiu ir embora.
Não é falta de ping-pong na sala de reunião. Não é porque o concorrente ofereceu home office. Esses são os motivos que aparecem na entrevista de desligamento porque são os seguros de dizer. Os motivos reais são outros.
Gestão ruim destrói retenção mais rápido que qualquer salário
Tem um ditado que soa clichê mas é empiricamente verdadeiro: pessoas não saem de empresas, saem de gestores. Já vi dev recusar proposta 40% maior pra ficar com um tech lead que confiava nele e dava autonomia real. E já vi dev aceitar aumento de 10% só pra sair de um gestor que microgerenciava todo PR.
Gestão ruim em dev tem formas específicas. O gestor que nunca foi técnico e mesmo assim opina no código sem ter base — e quando o dev discorda, vira 'atitude'. O gestor que marca reunião de status todo dia pra 'saber como tá o progresso' mas na prática só cria ansiedade e fragmenta o tempo de foco. O gestor que leva crédito pelo trabalho do time mas repassa a culpa quando algo dá errado.
O que funciona é o oposto: gestor que protege o time de interrupções externas, que defende as decisões técnicas do dev nas reuniões acima, que pergunta 'o que você precisa pra destravar isso?' em vez de 'quando vai ficar pronto?'. Esse tipo de gestão não é coisa rara — é coisa que requer intencionalidade. E empresas que investem nisso retêm dev bom por anos.
Código legado sem plano é uma forma lenta de burnout
Dívida técnica em si não mata ninguém. Toda empresa tem. O problema é quando vira parte da identidade do produto sem nenhuma conversa honesta sobre como lidar com ela. Quando o dev pergunta 'quando vamos refatorar esse módulo?' e a resposta é 'não tá no roadmap', semana após semana, mês após mês — a mensagem que ele recebe é: seu julgamento técnico não importa.
Tem um padrão que eu vi repetir em várias empresas. O sistema vai ficando cada vez mais frágil. Cada deploy vira um momento de ansiedade. Adicionar uma feature nova quebra três coisas que funcionavam. O time passa mais tempo corrigindo regressão do que entregando valor. Nesse contexto, a estimativa de qualquer tarefa fica impossível — porque ninguém sabe o que o código legado vai fazer quando você mexer nele.
Dev bom nesse cenário tem duas opções: aceitar ser um bombeiro permanente ou ir pra uma empresa que pelo menos reconhece o problema e tem algum plano. A maioria vai pra segunda opção quando a situação fica insuportável. E aí a empresa perde exatamente quem tinha o contexto pra resolver o problema.
O paradoxo do código legado
A empresa não quer investir em refatoração porque parece não entregar valor imediato. Os devs mais experientes saem frustrados. Quem fica são os que têm menos opções. O sistema piora. O custo de manutenção sobe. No final, a empresa paga muito mais do que teria gasto se tivesse dado espaço pro time cuidar do código desde o início.
Salário defasado: os números que ninguém quer colocar na mesa
Vou ser direto com números que circulam no mercado em 2026. Dev pleno em São Paulo, stack moderna (Node, React, TypeScript), trabalha numa empresa que paga R$ 8.000 CLT. O mercado paga R$ 11.000 a R$ 14.000 pra o mesmo perfil. A diferença parece abstrata até o momento em que o dev recebe uma proposta no LinkedIn e faz a conta.
O pior cenário é quando a empresa sabe que está pagando abaixo do mercado e tenta segurar com benefícios que na prática não compensam. Gympass, day off no aniversário e vale-refeição não fecham uma diferença de R$ 4.000 líquidos por mês. O dev sabe fazer essa conta.
O que funciona é ter transparência proativa. Empresa que revisa salários anualmente baseando no mercado, sem o dev precisar pedir, retém muito mais. Porque ela sinaliza que valoriza a pessoa antes de ela começar a buscar alternativas. Quando o dev já tem uma oferta na mão pra negociar, na maioria das vezes já decidiu sair — a negociação é só protocolo.
O que empresas que retêm devs fazem diferente
Não é segredo. As empresas que retêm talento técnico de verdade fazem coisas específicas que dá pra observar, listar e replicar. O problema é que a maioria prefere inventar um programa de 'cultura' do que fazer o trabalho real.
O que empresas que retêm devs bons fazem na prática:
Se você é o dev pensando em sair agora
Leia isso antes de mandar a carta
Primeiro: seu sentimento é válido. Se você está pensando em sair, provavelmente tem um motivo real. Não minimize isso.
Segundo: antes de sair, tente ter a conversa difícil. Não de forma ultimato, mas honesta. 'Estou sentindo que não tem espaço pra eu crescer aqui. O que você acha que pode mudar?' Às vezes a empresa não sabe que vai te perder até você dizer. E às vezes sabe, e aí você confirma que é hora de ir.
Terceiro: saia pra algo, não só de algo. Sair de uma situação ruim sem ir pra algo melhor definido é trocar um problema por um próximo problema. Tenha clareza do que você quer — mais salário, mais autonomia, stack diferente, trabalho remoto — antes de assinar qualquer proposta.
Quarto: o mercado em 2026 ainda absorve dev bom. Mas o processo de entrevista pode demorar. Tenha uma reserva. Não saia no impulso da pior semana.
Perguntas frequentes
O que muda na prática com «Gestão ruim destrói retenção mais rápido que qualquer salário»?
Comece pelo mecanismo descrito: Tem um ditado que soa clichê mas é empiricamente verdadeiro: pessoas não saem de empresas, saem de gestores. Já vi dev recusar proposta 40% maior pra ficar com um tech lead que confiava nele e dava autonomia real. E já vi dev aceitar aumento de 10% só pra sair.
Como testar «Código legado sem plano é uma forma lenta de burnout» sem overbuild?
Use o critério do material: Dívida técnica em si não mata ninguém. Toda empresa tem. O problema é quando vira parte da identidade do produto sem nenhuma conversa honesta sobre como lidar com ela. Quando o dev pergunta 'quando vamos refatorar esse módulo?' e a resposta é 'não tá no. Se precisar de segundo sinal, Tem um padrão que eu vi repetir em várias empresas. O sistema vai ficando cada vez mais frágil. Cada deploy vira um momento de ansiedade. Adicionar uma feature nova quebra três.
Qual erro comum aparece em «Salário defasado: os números que ninguém quer colocar na mesa»?
O artigo alerta: Vou ser direto com números que circulam no mercado em 2026. Dev pleno em São Paulo, stack moderna (Node, React, TypeScript), trabalha numa empresa que paga R$ 8.000 CLT. O mercado paga R$ 11.000 a R$ 14.000 pra o mesmo perfil. A diferença parece abstrata até o. Ajuste ao seu contexto em `por-que-devs-bons-pedem-demissao` antes de virar regra.
Como resumir «O que empresas que retêm devs fazem diferente» em uma decisão?
Resposta direta do corpo: Não é segredo. As empresas que retêm talento técnico de verdade fazem coisas específicas que dá pra observar, listar e replicar. O problema é que a maioria prefere inventar um programa de 'cultura' do que fazer o trabalho real.