Por muito tempo eu medi minha evolução pelo que eu conseguia construir. Um framework novo aprendido, um tipo novo de app entregue, mais uma linha na seção de stack do currículo. Parecia o placar certo, porque no começo ele quase era.
O que eu não percebi foi o momento em que o placar parou de refletir o jogo. O código não ficou exatamente mais fácil. Ele só deixou de ser a parte que me tirava o sono. A parte difícil tinha ido para outro lugar: decidir o que construir, decidir o que não construir e conviver com as consequências das duas coisas.
Este post é uma tentativa de descrever essa mudança do jeito que eu vivi. Não é um método para decidir quem é sênior. Títulos significam coisas diferentes em empresas diferentes e em mercados diferentes. Em 2025 eu fui Software Engineer numa empresa e Senior Software Engineer em outra, ao mesmo tempo, e alguns meses depois Full Stack Developer numa terceira. O trabalho por trás desses títulos era bem menos diferente do que as palavras. Então leia isto como a visão de um engenheiro sobre como os problemas mudaram, não como uma escada que todo mundo precisa subir.
Júnior: aprendendo a executar
Eu comecei em 2022, prototipando um app de delivery, web e mobile, enquanto ainda estava na faculdade. Eu estava sozinho nele, o que significava que eu tomava todas as decisões: a arquitetura, o modelo de dados, como as peças conversavam entre si. Por um tempo eu tomei isso como sinal de que estava mais adiantado do que realmente estava.
Levei anos para entender a diferença. Tomar decisões que ninguém revisa não é a mesma coisa que tomar boas decisões. Ninguém me dizia que uma escolha estava errada, então eu presumia que não estava. Eu tomava decisões de arquitetura sem saber quais eram as alternativas, quanto elas custavam ou o que ia quebrar seis meses depois. Eu não sabia o que eu não sabia.
Quando entrei num time em 2024, trabalhando em apps web e mobile com React, Next.js, React Native e Flutter, o formato do meu trabalho ficou mais claro, e sendo honesto, mais confortável. As tarefas chegavam bem definidas. Alguém já tinha decidido o que a tela devia fazer; meu trabalho era fazer ela fazer aquilo. A pergunta que eu fazia o dia inteiro era:
"Como eu implemento isso?"
Essa não é uma pergunta pequena. Naquela fase ela é a pergunta certa. Você está aprendendo a stack, o código, as convenções que ninguém escreveu, e a diferença entre código que funciona na sua máquina e código que sobrevive ao review. Eu precisava de orientação com frequência, e precisava que ela fosse específica.
Olhando para trás, a principal coisa que eu estava construindo não eram features. Era execução: a capacidade de pegar algo definido e transformar em software funcionando, sem drama. Tudo o que veio depois depende disso. Não dá para raciocinar sobre trade-offs num código que você ainda tem dificuldade de escrever.
Pleno: aprendendo a ser dono
A passagem para pleno não veio com um tipo novo de tarefa. Veio com menos instrução junto do mesmo tipo de tarefa.
Em vez de "constrói essa tela", passou a ser "a gente precisa dessa integração". Trabalhei em integrações com Mercado Livre, Shopee e Meta, e fiquei responsável por publicar e manter apps iOS pela Apple Developer: o ciclo de release, as diretrizes de revisão da App Store, a parte do trabalho que começa depois que o pull request é mergeado. Essa última parte me ensinou algo que o código nunca ensinou. Uma feature não está pronta quando funciona. Está pronta quando está na mão do usuário e continua funcionando.
Sistemas externos te obrigam a aprender isso. As APIs deles dão timeout, mudam sem aviso, mandam o mesmo evento duas vezes ou respondem com sucesso com metade dos dados faltando. Então as perguntas que eu fazia começaram a mudar. O que acontece quando essa chamada falha? E se esse webhook chegar duas vezes? Como eu testo isso sem cobrar um cartão de verdade? Como eu vou saber que quebrou em produção antes de um cliente me contar?
A pergunta por baixo de todas elas era:
"Qual é o melhor jeito de resolver isso?"
Essa pergunta parte do princípio de que o problema já está certo. Outra pessoa decidiu o que estamos resolvendo; eu decido como. Passei a ser responsável por edge cases, testes, performance e deploy, e precisava de cada vez menos detalhe no ticket para entregar.
É um degrau real, e por um tempo parece que é o trabalho inteiro. Confiam em você. Você entrega. As pessoas param de conferir cada linha. É fácil acreditar que o próximo passo é só mais do mesmo: features maiores, sistemas mais complexos, mais tecnologias.
Para mim não foi.
Sênior: aprendendo a decidir
O sinal mais claro de que meu trabalho tinha mudado foi que eu comecei a receber problemas em vez de tarefas.
Não "constrói X", mas "essa tela está lenta", "esse sistema precisa sair do Firestore", "os clientes não conseguem pagar e a gente não sabe por quê". Sem especificação, às vezes sem um dono claro, e muitas vezes com informação incompleta sobre o que estava acontecendo de verdade.
Novos problemas
Os próprios problemas mudaram de formato. Passaram a ser menos sobre uma feature e mais sobre um sistema que já estava rodando, com gente dependendo dele.
Um ERP focado em gestão de frotas em que trabalhei precisava migrar o core do Firestore para o PostgreSQL, e seis produtos separados precisavam ser consolidados em um único deploy multi-tenant. A restrição que moldou tudo foi que a operação não podia parar. Escrever o schema novo não era a parte difícil. A parte difícil era decidir como migrar módulo a módulo, o que podia coexistir e por quanto tempo, e que risco a gente aceitava em cada etapa. Nada disso cabe num ticket.
Novas responsabilidades
As responsabilidades também mudaram, e foram mais difíceis de perceber, porque ninguém entrega elas num ticket.
- O que acontece depois do deploy. Num produto web e mobile usado por milhares de pessoas, ser responsável significou crash reporting, logs e métricas: saber que algo quebrou antes de um cliente contar.
- Dinheiro e dados dos outros. Pagamentos e webhooks, em que o mesmo evento pode chegar duas vezes e um retry descuidado cobra alguém de novo. E decidir o que não coletar: num fluxo de pagamento, o que ficou de fora da instrumentação importou tanto quanto o que foi capturado.
- Traduzir trade-offs. Explicar para quem não lê código do que estamos abrindo mão, por quê, e quanto isso vai custar depois.
- Construir menos. Questionar se a feature pedida resolve o problema, e às vezes argumentar contra construí-la.
- Assumir a decisão. Decidir sem alguém validando cada passo, e assumir quando ela se mostra errada.
Construir um produto do zero de novo foi o que deixou a diferença óbvia para mim. Em 2022, sozinho no app de delivery, eu tomava todas as decisões e ninguém pagava por nenhuma delas. Construindo do zero uma plataforma multi-tenant de automação de marketplace, com integrações, pagamentos e fluxos de pedido, eu voltei a tomar a maior parte das decisões. A autonomia era a mesma. O peso era completamente outro: do outro lado de cada decisão havia clientes pagando.
Então a pergunta mudou de novo:
"Qual problema a gente está realmente tentando resolver?"
Essa pergunta é desconfortável. Às vezes a resposta é que a feature que alguém pediu não resolve o problema que essa pessoa tem. Às vezes é "eu ainda não sei, e é assim que a gente descobre". De um jeito ou de outro, agora a resposta é minha.
Confiante, e parado
Tem uma parte desse período que eu não esperava. Quanto mais eu crescia, mais confiante eu me sentia. E, ao mesmo tempo, mais parado. Eu conseguia entregar. Conhecia bem a stack, os sistemas, a produção. Essa confiança ajudava a tomar decisões, mas era péssima para me mostrar onde eu tinha parado de crescer.
O que me fez andar de novo não foi uma tecnologia nova. Foram pessoas. Passei a ter mais ajuda de devs mais experientes: staffs, managers, seniors, pessoas que tinham de experiência o que eu tenho de idade. Isso me ensinou muito, e pouquíssimo disso era sobre sintaxe. Boa parte do que eu descrevi acima, as perguntas que eu faço antes de escrever qualquer coisa, eu aprendi vendo como elas trabalhavam.
A outra direção me surpreendeu mais. Ajudar pessoas que estão no começo da carreira também me ajudou. Explicar uma coisa é o jeito mais rápido de descobrir se você realmente entende, e responder às dúvidas de outra pessoa te obriga a organizar o que você sabe. Isso moldou como eu estudo, como eu aplico o que aprendo e como eu repasso o conhecimento.
Acho que essa é a parte da senioridade que não cabe num currículo: aprender com quem está à sua frente enquanto ajuda quem está começando, ao mesmo tempo.
O problema muda
Se eu tivesse que resumir a mudança inteira numa frase, seria esta: o código continua difícil, mas deixa de ser o gargalo.
O que passa a ser difícil:
- Descobrir o que realmente precisa ser construído. Os requisitos chegam incompletos, e a parte que falta costuma ser a parte importante.
- Escolher trade-offs. Toda opção custa alguma coisa. O trabalho é saber o quê, e dizer isso em voz alta.
- Trabalhar dentro de sistemas existentes. A maior parte do trabalho real não é greenfield. É mudar algo de que as pessoas dependem enquanto elas estão usando.
- Prever consequências. O schema que você escolhe hoje decide o que vai ser barato e o que vai ser doloroso pelos próximos dois anos.
- Trabalhar com incerteza. Decidir com 60% da informação porque esperar pelos 100% custa mais.
- Equilibrar velocidade e qualidade. Não como slogan. Como uma escolha concreta, numa feature específica, nesta semana.
- Entender o impacto. Um erro de frontend no checkout não é bug de UI. É receita perdida que nenhum dashboard técnico mostra.
Nada disso substitui código. Fica em cima dele. Você ainda precisa escrever a query, o componente, a migration. Mas a hora mais difícil da semana raramente acontece no editor.
O mercado percebe
Demorei para perceber que o mercado acompanhava essa mesma mudança, só que com atraso.
No começo, o jeito como você é avaliado é quase todo legível num currículo: quais tecnologias você conhece, quais frameworks, quais projetos construiu, quantos anos de experiência tem, se consegue implementar uma feature. Faz sentido. Nessa fase, esses são mesmo os melhores sinais de que você consegue executar.
Conforme o escopo cresce, esses sinais deixam de bastar. O que passa a importar é mais difícil de listar:
- ownership: se as coisas que você toca chegam ao fim, incluindo o que vem depois do deploy
- autonomia: quanta direção você precisa para fazer um problema andar
- tomada de decisão, e se você consegue explicar as decisões que tomou
- arquitetura, não como diagrama, mas como consequência
- impacto no produto, não só volume de entrega
- comunicação, principalmente sobre trade-offs e risco
- conforto com ambiguidade
- a capacidade de conectar uma escolha técnica ao que o negócio está tentando fazer
O que muda não é só como você é avaliado. É o tipo de oportunidade que aparece. Tarefas com escopo fechado viram problemas abertos. "Você consegue construir isso?" vira "você consegue descobrir o que a gente deveria fazer aqui?". A confiança é outra, e a responsabilidade que vem junto também.
Quero tomar cuidado aqui. Isto não é uma promessa de salário nem um caminho de carreira garantido. Mercados mudam, empresas mudam, e muita gente é subestimada ou superestimada por motivos que não têm nada a ver com nada disso. É só o que eu percebi: o valor percebido tende a acompanhar o tamanho dos problemas que confiam a você, mais do que o tamanho da sua lista de stack.
O que mudou para mim
Se você comparar minha stack de 2022 com a de hoje, ela cresceu. Mas não foi isso que mudou. Eu poderia listar todas as tecnologias que já usei e isso não explicaria a diferença entre como eu trabalhava naquela época e como trabalho agora.
O que mudou foi por onde eu começo. Eu começava pela implementação. Hoje começo pelo problema, e tento desconfiar dele antes de confiar. Pergunto o que acontece depois do deploy, quem percebe quando quebra e do que a gente está abrindo mão. Parei de tratar "ninguém se opôs" como "estava certo".
Também mudei o que considero pronto. Pronto já significou mergeado. Depois significou em produção. Hoje significa que o problema foi de fato resolvido, e que eu consigo explicar por que esta solução e não outra.
E quase nada disso eu descobri sozinho. Veio de pessoas que já tinham passado por ali antes de mim, e de ter que explicar para quem ainda não tinha passado.
Ainda estou aprendendo
Não acho que cheguei a lugar nenhum. Tem coisas em que eu ainda estou trabalhando: saber quando o bom o suficiente realmente é suficiente, distinguir um trade-off de um atalho, e dizer "eu errei" mais rápido do que eu dizia. E continuo aprendendo do mesmo jeito que aprendi quase tudo: com quem está mais à frente, e explicando para quem está começando.
E tenho quase certeza de que parte do que eu acredito hoje vai me parecer ingênuo daqui a alguns anos, do mesmo jeito que minhas primeiras decisões de arquitetura me parecem agora. Tudo bem. Acho que esse é o ponto.
Código vai continuar fazendo parte do trabalho. Eu ainda gosto dele, e desconfio de engenheiros que param de se importar com ele. Mas em algum momento, escrever código deixa de ser a parte difícil. A parte difícil é tudo em volta: entender o problema, escolher do que abrir mão e assumir o resultado.
Essa é a parte que eu ainda estou aprendendo.