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.
- Motivo 1 — Crescimento estagnado: O dev parou de aprender. Toda semana é a mesma tarefa, a mesma stack, o mesmo nível de complexidade. Quando não há desafio, o bom dev não fica parado — ele vai procurar desafio em outro lugar. Dev ruim tolera estagnação. Dev bom não.
- Motivo 2 — Gestão que não respeita a expertise técnica: O gestor toma decisões técnicas importantes sem consultar quem é técnico, ou pior, ignora as objeções de quem é técnico. Nada desmotiva mais um dev sênior do que saber que a solução vai dar errado, avisar, ser ignorado e assistir ao incêndio em produção.
- Motivo 3 — Dívida técnica acumulada sem plano: Todo sistema tem dívida técnica. O problema é quando ela cresce indefinidamente sem nenhum espaço no roadmap pra resolver. Trabalhar num código que você sabe que está errado, sabendo que ninguém vai deixar você corrigir, é desgastante de um jeito que não tem nome bonito.
- Motivo 4 — Salário defasado sem perspectiva de revisão: O mercado paga X. A empresa paga 0,7X. O dev sabe disso porque LinkedIn existe. Enquanto o salário estava aceitável, ficava pela cultura, pelo time, pelos projetos interessantes. Quando a diferença cresceu demais, o pacote todo deixou de compensar.
- Motivo 5 — Ambiente tóxico normalizado: Reuniões que poderiam ser email. Pressão constante sem reconhecimento. Colegas que fazem política em vez de código. Cultura de heroísmo onde quem trabalha de madrugada é celebrado em vez de ser visto como sintoma de planejamento ruim. Dev bom tem opções. Quando o ambiente fica pesado, ele usa.
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:
- Revisão salarial proativa — sem o dev precisar ameaçar sair pra receber um ajuste
- Tech lead ou gestor técnico com credibilidade real no time — não alguém promovido por senioridade
- Espaço no roadmap pra melhoria técnica — pelo menos 20% do tempo, regularmente
- Autonomia real pra decisões técnicas dentro do escopo do dev
- Feedback de carreira honesto e com frequência — não só na avaliação anual
- Cultura que trata incidente como aprendizado, não como busca de culpado
- Reuniões com propósito claro — e que poderiam ser email quando for o caso, são email
- Reconhecimento público quando o trabalho tem impacto real no produto
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.
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.
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.