Um relato publicado no dev.to nesta semana juntou 68 reações e 39 comentários em cima de uma dor que muita gente em início de carreira reconhece na hora: você entra no primeiro emprego achando que vai aprender engenharia de software e descobre que, antes disso, vai aprender processo, sistema legado, suporte, revisão em várias camadas e um monte de operação que já existia muito antes de você chegar.
No post, o autor conta que caiu num ambiente grande, com tecnologia antiga, forte peso de manutenção e regras sérias de privacidade. Em vários momentos, ele precisava alterar campo, registro ou valor seguindo manual — mas sem entender direito o motivo daquela mudança específica. E esse detalhe importa muito, porque é aí que começa a sensação de estar executando sem realmente compreender.
Esse caso vale a leitura porque não é só um desabafo. Ele explica por que tanta gente boa entra em TI, acerta o procedimento e mesmo assim passa semanas achando que talvez não seja boa o bastante.
o choque não é só com o código
A imagem romantizada do primeiro emprego em engenharia costuma ser simples: escrever código, aprender stack, tomar pancada de bug, melhorar aos poucos.
No relato, a realidade veio por outro caminho. O trabalho tinha mais cara de sustentação do que de construção. Menos espaço para “vamos refatorar isso” e mais necessidade de seguir um fluxo já validado, porque o sistema era crítico e outras pessoas dependiam dele.
É um choque comum em empresa grande. E ele pesa mais quando o profissional ainda está tentando entender duas coisas ao mesmo tempo:
- o sistema em si
- o motivo de cada regra que cerca o sistema
Quando essa segunda camada não fica clara, a pessoa até consegue fazer a task, mas não cresce na mesma velocidade em entendimento.
a parte que mais mexe com a cabeça de quem está começando
O trecho mais forte do relato não é sobre acordar cedo nem sobre tecnologia velha. É sobre fazer mudanças corretas sem saber exatamente por quê.
Manual manda conferir campos. Processo manda passar por revisão. A liderança pede urgência. Só que a cabeça de quem está começando segue fazendo a pergunta mais importante: o que esse valor muda no mundo real?
Quando a resposta não vem, nasce um tipo de insegurança bem específico. Não é só medo de errar. É a sensação de estar perto do sistema, mas longe do contexto.
Isso conversa direto com um benchmark brasileiro da GeekHunter sobre onboarding técnico. O ponto central deles é simples: novo dev demora a engrenar não só porque precisa aprender ferramenta, mas porque boa parte do conhecimento real está espalhada entre pessoas, atalhos informais e decisões antigas mal documentadas.
simulação treina uma coisa. produção cobra outra
Outro ponto que o texto do dev.to acerta bem é a diferença entre treinamento e ambiente real. O autor passou por etapas de KT, simulação e depois mãos na massa. Na teoria, parece um onboarding organizado. Na prática, a virada para ferramenta real trouxe detalhes que a simulação não tinha como ensinar por completo.
Quem já entrou em operação mais séria conhece esse momento. Na simulação, você aprende a sequência. Em produção, você aprende peso, impacto, exceção, ruído de comunicação e tudo aquilo que não cabe direito em tutorial.
É por isso que o começo em sistema legado pode parecer tão confuso. O problema não é só a complexidade técnica. É a soma de:
- contexto de negócio que chega picado
- ferramenta lenta ou limitada
- revisão em várias camadas
- urgência antes da compreensão completa
- comparação inevitável com gente que já carrega anos de repertório
nem toda insegurança de júnior é falta de capacidade
Esse talvez seja o recado mais útil do caso.
No relato, o autor reconhece erros próprios, fala de falhas repetidas e não tenta posar de vítima. Ao mesmo tempo, ele também percebe uma coisa que muita empresa demora a admitir: dá para responsabilizar alguém pelo trabalho sem fingir que ela controla o desenho inteiro do trabalho.
Ferramenta ruim atrasa. Processo confuso atrasa. Comunicação em camadas atrasa. Conhecimento preso na cabeça dos mais antigos atrasa. E tudo isso pesa ainda mais quando o time espera produtividade de quem acabou de sair da fase de simulação.
Traduzindo para o leitor brasileiro: às vezes o júnior não está travando porque “não nasceu para isso”. Ele está travando porque entrou por uma porta em que o contexto veio parcelado, a régua já estava lá em cima e quase ninguém conseguiu explicar o mapa inteiro.
o primeiro emprego também serve para descobrir o que você não quer
Tem outra honestidade boa no texto: em certo ponto, o autor admite que talvez simplesmente não goste daquele tipo de trabalho.
Suporte e manutenção em mainframe não eram o que ele imaginava para a própria carreira. E perceber isso cedo não é fracasso. É informação.
Muita gente trata o primeiro emprego como teste definitivo de vocação: “se eu gostei, escolhi certo; se eu não gostei, talvez eu não sirva para TI”. Só que a vida real é mais torta que isso. Às vezes o primeiro emprego não revela se você serve para a área. Revela só que aquele recorte específico — legado, sustentação pesada, rotina muito procedural — não é o lugar em que você quer ficar por anos.
Esse tipo de descoberta também vale.
o que esse caso deixa para quem está entrando agora
Se você está no começo e se identificou com o relato, talvez a leitura mais útil seja esta:
- nem sempre o desconforto inicial é prova de incompetência
- entender o “porquê” das regras muda mais a evolução do que decorar o passo a passo
- empresa grande costuma testar mais contexto e comunicação do que a fantasia de “só codar”
- onboarding bom não é o que despeja informação; é o que distribui contexto
- descobrir cedo o tipo de trabalho que você não quer seguir também é avanço de carreira
O post do dev.to pegou porque falou de algo muito reconhecível: o começo em TI às vezes parece menos uma aula de engenharia e mais um choque de realidade operacional. E, honestamente, isso ajuda a explicar muita insegurança que o mercado gosta de tratar como falha individual.
Para quem lidera time, o caso deixa um aviso simples: se o novo profissional executa, mas não entende, o problema ainda não foi resolvido. Ele só foi empurrado para dentro do processo.
Fontes
- https://dev.to/itsugo/my-first-engineering-job-is-teaching-me-something-i-didnt-expect-l96
- https://www.geekhunter.com/pt/blog/por-que-novos-desenvolvedores-demoram-tanto-para-se-tornar-produtivos-4-praticas-para-melhorar-o-onboarding-tecnic/
