Um relato publicado no r/brdev nesta sexta-feira resume um problema que muita gente em tecnologia sente antes de conseguir nomear: ter anos de experiência no currículo, mas pouca sensação de evolução real.
O autor diz estar no 7º período de Engenharia de Software, com cerca de três anos de experiência “picada”. Passou por estágio, foi efetivado, perdeu espaço quando não havia vaga clara para dev, depois trabalhou em uma empresa de iGaming/apostas com Flutter, automações, OCR e ferramentas variadas. O ponto central do relato não é falta de esforço. É o contrário: ele aprendeu a se virar, mas sem senioridade por perto, sem processo forte e sem uma trilha clara de crescimento.
Agora, segundo o post, ele está em uma empresa de software para gestão de fazendas/agrotech como Dev PJ, ganhando R$ 3.500, em uma rotina descrita como “100% apagar incêndio”. Quase não escreve código novo. Passa o dia investigando problemas em sistema legado, usando Claude e outras LLMs para entender partes do sistema e fazendo correções diretas no banco de dados.
A frase mais importante do caso é esta: por um lado, ele sente que está ganhando prática em resolução de problemas e banco de dados; por outro, sente que não está evoluindo como engenheiro/desenvolvedor.
O problema não é trabalhar com legado
Legado não é castigo automático. Muito dev bom foi formado mexendo em sistema antigo, lendo regra de negócio esquisita, entendendo banco mal documentado e descobrindo por que uma tela “simples” derruba três rotinas do financeiro.
O problema começa quando legado vira só emergência.
Quando a rotina é abrir chamado, investigar erro, corrigir dado direto no banco e correr para o próximo incêndio, a pessoa aprende bastante sobre sobrevivência. Mas nem sempre aprende engenharia. Faltam revisão, desenho de solução, teste, documentação, decisão técnica, conversa com produto, observabilidade, deploy com menos susto e entendimento de trade-off.
É possível crescer muito em manutenção. Mas manutenção boa não é bagunça permanente. Ela tem método.
Experiência “picada” pode enganar o currículo
Três anos de experiência não significam automaticamente três anos de progressão. Às vezes significam um ano repetido três vezes, em contextos diferentes.
No caso relatado, dá para ver alguns sinais clássicos:
- passagem por áreas e projetos sem continuidade clara;
- pouco contato com devs mais experientes;
- muita autonomia antes de existir base técnica sólida;
- tarefas variadas demais para formar profundidade;
- pressão operacional alta com salário baixo para o nível de desgaste.
Isso não torna a experiência inútil. Pelo contrário. Quem passa por esse tipo de ambiente costuma desenvolver casca, leitura de problema e velocidade para se virar. Só que essa experiência precisa ser traduzida. Se ficar apenas como “apaguei incêndio em sistema legado”, o mercado pode enxergar bagunça, não maturidade.
O uso de IA muda o cenário, mas não resolve a falta de mentoria
Um detalhe do relato chama atenção: o uso de Claude/LLMs para entender legado. Isso já é realidade em muita equipe. A IA ajuda a atravessar código confuso, resumir trechos, sugerir hipótese e acelerar investigação.
Mas existe uma armadilha aí. Se a empresa usa IA para compensar falta de documentação, falta de processo e falta de senioridade, o dev júnior ou pleno inicial continua sozinho. Só que agora sozinho com uma ferramenta mais convincente.
LLM pode explicar uma função. Não substitui alguém dizendo: “essa correção direta no banco deveria virar script versionado”, “essa regra precisa de teste”, “esse bug revela uma falha de modelagem”, “isso aqui precisa de postmortem, não só hotfix”.
Essa diferença é enorme para carreira.
O que dá para extrair de valor dessa fase
Se você está em uma situação parecida, a primeira reação é querer sair correndo. Às vezes é mesmo o caminho. Mas enquanto a transição não vem, dá para transformar parte da bagunça em material de evolução.
O primeiro passo é registrar problemas de forma profissional. Não precisa expor empresa nem dado sensível. Monte um diário técnico privado com padrão simples:
- qual era o sintoma;
- como você investigou;
- qual era a causa provável;
- qual correção foi aplicada;
- como aquilo poderia ser prevenido;
- que teste, alerta ou documentação faltava.
Isso muda a narrativa. Você deixa de ser “o dev que mexe no banco quando quebra” e começa a construir repertório de diagnóstico, manutenção e melhoria de sistema.
O segundo passo é escolher uma área para aprofundar fora do caos. Se o trabalho atual te joga em banco de dados, legado e bugs de produção, talvez sua próxima trilha natural seja backend, qualidade, observabilidade, dados ou sustentação com engenharia de verdade. O erro seria tentar compensar a ansiedade estudando tudo ao mesmo tempo: frontend moderno, mobile, cloud, IA, arquitetura, DevOps, concurso, inglês, freelance e mais dez coisas.
Carreira não melhora só com volume de estudo. Melhora com direção.
Portfólio não precisa ser vitrine perfeita, precisa provar maturidade
As fontes brasileiras de carreira que costumam orientar iniciantes batem bastante na tecla de portfólio, GitHub, README e projetos autorais. Isso faz sentido, mas para um caso como esse o portfólio não deveria ser só “mais um CRUD bonito”.
Um dev que vive apagando incêndio pode criar projetos pequenos que provem justamente o que faltou no trabalho:
- uma API simples com testes e migrations bem feitas;
- um projeto legado refatorado em etapas, com antes/depois documentado;
- um mini sistema com logs, tratamento de erro e README decente;
- um estudo de caso explicando como investigaria um bug de produção;
- um script seguro para correção de dados, em vez de update manual solto.
Isso é mais forte do que tentar parecer sênior no LinkedIn. Mostra que a pessoa entendeu o buraco onde caiu e está construindo a escada para sair.
Quando o salário baixo vira alerta de rota
R$ 3.500 PJ para uma rotina estressante, com legado, banco e pressão operacional, acende alerta. Não porque todo começo de carreira precise pagar alto, mas porque PJ sem estrutura, sem mentoria e com cobrança de produção costuma transferir risco demais para quem ainda está se formando.
O ponto prático é separar duas perguntas:
Estou aprendendo algo que aumenta meu valor de mercado?
O desgaste que estou aceitando tem prazo e plano?
Se a resposta for “não” para as duas, a vaga pode estar consumindo energia sem devolver carreira. Aí o objetivo deixa de ser “aguentar mais um pouco” e vira preparar saída com critério: currículo mais claro, portfólio orientado a problemas reais, busca por empresas com time técnico melhor e entrevistas em que você pergunte sobre revisão, onboarding, documentação e rotina de deploy.
O recado maior para quem está entrando em TI
O relato não diz que a carreira acabou. Também não prova que todo júnior está condenado. Ele mostra algo mais concreto: experiência sem ambiente de crescimento pode virar um labirinto.
Para quem está começando, a pergunta não é só “qual stack dá dinheiro?”. É também:
- vou ter alguém melhor do que eu para revisar meu trabalho?
- essa empresa tem processo mínimo ou vive de urgência?
- vou construir algo que consigo explicar depois?
- essa rotina me aproxima ou me afasta da vaga que quero daqui a um ano?
Apagar incêndio ensina. Mas, se ninguém te deixa investigar a causa, desenhar prevenção e evoluir o sistema, você vira só a pessoa com o extintor na mão.
E carreira em TI precisa de mais do que sobreviver ao próximo chamado.
