Muitas vezes, o que diferencia um desenvolvedor júnior de um sênior vai além do domínio técnico. Quando estamos começando tudo parece uma zona cinzenta, eu também passei por isso.
o que ninguém te conta sobre "virar" sênior
Conheci desenvolvedores geniais. Gente que construiu frameworks, programadores competitivos, pessoas capazes de fazer o que quisessem com sua linguagem favorita.
Mas o que realmente faz alguém ser considerado sênior ou especialista?
Quando eu era estagiário, minha dúvida era: o que me falta pra ser júnior?
Depois que virei júnior: por que ainda não me sinto pleno?
E assim por diante, entre momentos de síndrome do impostor e momentos de complexo de Deus.
Comecei cedo na programação. Sendo autodidata, aprendi as coisas conforme elas surgiam: linguagens, frameworks, estratégias. Tudo separado e muitas vezes as pontas pareciam não se conectar.
Em 2019, depois de dois anos estudando programação por conta própria, entrei na faculdade esperando que o diploma me desse confiança para atuar como dev. Então decidi acelerar esse processo:
Participei de iniciações científicas, hackathons (inclusive fui premiado), eventos de empreendedorismo e até entrei pro time de xadrez nos jogos universitários (falhei miseravelmente).
Entre idas e vindas, consegui meu primeiro estágio. E foi aí que a jornada da senioridade começou.
a síndrome do “faça funcionar”
No meu primeiro trabalho, fui jogado direto no fogo. Sem orientação técnica, cabia a mim resolver os problemas com código, eu não podia deixar essa oportunidade escapar.
Dai eu fazia funcionar.
Mas “fazer funcionar” é só o começo. Eu estava aprendendo a resolver problemas, mas eu tava longe de saber projetar soluções.
Ali comecei a desenvolver o que mais tarde conheceria como autonomia técnica, mas ainda sem maturidade de engenharia.
E tá tudo bem. Não é comum um iniciante tomar decisões de arquitetura. Mas ter essas oportunidades me gerou alguns insights.
quando ser júnior e pleno parecem a mesma coisa
Com o tempo, percebi que meu trabalho não era tão diferente do que os plenos faziam. A diferença estava na segurança com que eles decidiam.
Eu ainda não me sentia no direito de propor padrões, então eu seguia as orientações até começar a ter espaço nos debates. Isso foi essencial.
Fui atrás de participar de comunidades, vi documentários, assisti palestras e revisitei aquele material da faculdade que antes tinha ignorado.
Comecei a fazer meus próprios deploys, mesmo que simples.
Nessa fase também tive minha primeira experiência como "liderança técnica", ainda era muito informal mas pude tomar minhas primeiras decisões a nível de projeto.
Comecei a divulgar meu trabalho e isso abriu muitas portas. Quanto mais acesso eu tinha a conteúdo técnico profundo, mais percebia que o “trabalho trivial” do dia a dia começava a perder a complexidade.
Muitos desenvolvedores quando passam por esse filtro pensam que todas as soluções devem ser desnecessáriamente complexas, trazem maior verbosidade, querem desenvolver um código muito idiomático e mostrar que conhecem arquiteturas, teorias e ferramentas complexas, tudo isso no sistema com poucos clientes ou quase sem orçamento.
Pro código ser bom ele precisa ter sido feito com clean/onion architecture, DRY, KISS, SOLID, TDD, DDD e com muitas classes e design patterns e de preferência se tiver uma infraestrutura bem robusta rodando por baixo.
E foi aí que conheci o overengineering (ou a síndrome do pleno). Tudo por conta de uma vontade de conhecer as verdades, a bala de prata que poderia resolver qualquer problema.
a diferença entre conhecimento e experiência
Um dos tech leads que mais me ensinou me disse algo que nunca esqueci:
“Você já tem conhecimento de pleno. O que falta é transformar isso em experiência.”
Até ali, eu achava que o que faltava era aprender mais.
Na verdade, eu precisava viver mais situações reais, errar em decisões de design, ver sistemas falharem, refatorar serviços que eu mesmo criei errado. Realmente explorar o meu potencial.
Mesmo com muito estudo, minhas opiniões ainda eram enviesadas. Eu repetia padrões sem entender o contexto por trás.
Faltava profundidade.
Tempos depois, numa viagem a São Paulo, tive uma conversa com o líder em outro projeto. Ele me disse algo que virou a chave durante uma one on one:
“O que falta pra você ser sênior é um case. Um projeto bem-sucedido que valide suas decisões.”
E ainda completou:
“Você sabe como escalar o que você tá produzindo?”
a virada: pensar antes de fazer
Essa pergunta mudou meu jeito de trabalhar.
Senioridade começa a fazer a diferença quando você para de pensar só no que precisa ser feito e começa a visualizar como isso vai se comportar daqui a 6 meses, 1 ano ou 5 anos.
Você pode chamar de system design, arquitetura de software ou engenharia de soluções, mas o nome pouco importa.
Projetar sistemas não é desenhar caixinhas no Excalidraw.
É tomar decisões técnicas com impacto organizacional.
Quando você começa a entender os componentes do seu sistema como ferramentas a serem combinadas, seu nível de abstração sobe.
E toda aquela briga sobre “onde vai tal classe” vira detalhe, nos atentemos aos conceitos aplicados.
Boa arquitetura é sobre trade-offs, não sobre frameworks ou organização de pastas.
fechando o ciclo
Não existe um dia em que você acorda e é “sênior”.
O que existe é uma sequência de vivências, erros, tentativas, reflexões e decisões. Algumas conscientes, outras nem tanto.
Hoje, quando alguém me pergunta:
“O que falta pra eu virar sênior?”
Eu costumo responder:
“Em resumo, talvez seja só alguém te contratar com esse cargo.”
Continue desenvolvendo, escutando e pensando no que você está construindo. A resposta vem no caminho.
Hoje depois de mais uns anos, tendo passado por mais diversos projetos, a ideia que tenho é de que posso desenvolver qualquer solução, pra grande maioria dos requisitos mudando o quanto tempo eu demoraria pra poder resolver cada problema.
No fim, tudo trata-se do problema de homem-hora e de que tipo de problema você quer seja resolvido, sabendo que o que temos de diferencial é cada vez menos a quantidade de linhas de código que desenvolvemos, principalmente num mundo em que todos os programadores já têm uma LLM à sua disposição, mas sim a experiência e exposição a diferentes combinaçoes de ambiente e soluções.