O filtro invisível que separa quem cresce de quem estaciona

Existe um fenômeno curioso acontecendo na área de tecnologia: quanto mais o discurso sobre senioridade se espalha, mais básico parece estar o critério para defini-la.

Nos últimos tempos, o LinkedIn virou palco de uma encenação de posts onde profissionais "sêniores" compartilham insights com aura sofisticada, geralmente em inglês, acompanhados de exemplos simples — tratados como se fossem grandes descobertas de engenharia de software. Quando você remove o verniz do discurso, sobra uma constatação incômoda: aquilo não é avançado. É o básico do básico.

E isso levanta uma pergunta que deveria incomodar mais gente: quando o mínimo virou diferencial?

O básico com roupa de gala

Vamos ser objetivos sobre o que realmente está acontecendo.

Boa parte do que hoje aparece como "mentalidade sênior" nada mais é do que prática essencial de qualquer pessoa que já colocou código em produção em ambiente real. Tratar erros para não derrubar um fluxo inteiro. Saber quando reprocessar e quando não. Definir corretamente o início e o fim de uma transação. Não confiar cegamente em input externo. Parar de iludir a operação com serviços que estão fora do ar.

Esses conceitos ganharam nomes bonitos — Graceful Degradation, Idempotency, Circuit Breaker — mas, no fim do dia, continuam sendo obrigações básicas de quem escreve software que sobreviva ao mundo real. Não dominar isso não te torna "júnior". Te torna inseguro para produção. E existe uma diferença importante entre as duas coisas.

O júnior está aprendendo. Ele ainda não teve tempo de exposição suficiente para internalizar esses conceitos. Isso é esperado, faz parte do processo. Mas quando alguém com anos de experiência ainda trata o tratamento de exceções como técnica avançada, o problema não é falta de tempo — é falta de profundidade. E profundidade não se ganha acumulando anos. Se ganha enfrentando problemas reais e refletindo sobre eles.

O problema não é estudar padrões — é confundir o mapa com o território.

A analogia do futebol que ninguém quer ouvir

Imagine um jogador profissional se promovendo porque sabe dominar a bola e fazer um passe curto. Ninguém levaria isso a sério. Ele já parte do princípio de que está em campo — isso é o ingresso, não o que diferencia ninguém lá dentro.

Na programação, acontece exatamente a mesma coisa, mas por algum motivo a gente aceita. Saber escrever CRUD, tratar exceção, lidar com transações e validar input não te torna especial. Te torna funcional. É o ingresso mínimo para entrar em campo.

O que acontece depois que você está nele é o que define sua trajetória.

E aqui mora uma observação que poucos fazem: a maioria das pessoas nunca sai do aquecimento. Passam anos repetindo movimentos básicos, achando que estão jogando o jogo de verdade, quando na prática nunca saíram da área de treino. Não por falta de capacidade, mas por falta de consciência sobre onde realmente estão.

A IA como espelho incômodo

Talvez o ponto mais desconfortável dessa discussão seja este: muito do que hoje é vendido como competência técnica já foi superado por ferramentas automatizadas.

A IA escreve CRUD mais rápido do que você. Gera boilerplate mais consistente. Reduz erros triviais. Sugere estruturas melhores do que quem nunca estudou fundamentos. E isso não é futurologia — é o presente. Qualquer dev que use Copilot, Claude ou ChatGPT por meses já viu como o trabalho mecânico foi virando comodity competitiva.

Se o seu diferencial é apenas "saber programar", você já está competindo com algo que não cansa, não pede aumento e melhora a cada trimestre.

Isso não é um ataque à profissão. É um alerta sobre onde colocar energia.

A programação sempre foi meio, nunca foi fim. Ela é a ferramenta que usamos para resolver problemas, construir produtos, criar valor. Quando a ferramenta fica mais acessível, o que passa a importar é o que você faz com ela — não o saber usá-la. E essa mudança de eixo exige uma mudança de mentalidade que muita gente ainda não percebeu que precisa fazer.

O que o mercado valoriza (e o que ele diz que valoriza são coisas diferentes)

Empresas não pagam mais caro por quem sabe o óbvio. Elas pagam mais caro por quem resolve problemas com previsibilidade.

Essa frase parece simples, mas esconde uma verdade que leva anos para internalizar de verdade. O mercado valoriza quem entende impacto no negócio, não só impacto no código. Quem sabe equilibrar qualidade técnica com custo e prazo — não porque abre mão da qualidade, porque entende que qualidade sem contexto é perfeccionismo disfarçado. Quem toma decisões que evitam retrabalho e incidentes, porque já passou por incidentes suficientes para saber o custo real de decisões mal pensadas. Quem constrói sistemas sustentáveis, não apenas "funcionais" — porque funcional hoje e vira pesadelo em seis meses não é entrega, é dívida.

Acima de tudo, o mercado valoriza quem consegue explicar riscos, trade-offs e consequências. Não em termos técnicos para impressionar outros técnicos, mas em termos que permitam decisões informadas por quem está pagando a conta.

Nenhuma empresa cresce porque alguém escreveu um try-catch. Elas crescem porque alguém entrou num problema crítico, reduziu custo, ganhou escala ou entregou valor mais rápido. Sem isso, todo o resto é só código.

Crescer na carreira é trocar habilidade por responsabilidade

Aqui está um ponto que muita gente ignora, talvez porque seja desconfortável: crescer na carreira não é saber mais frameworks. É assumir mais responsabilidade.

Responsabilidade sobre decisões — e sobre as consequências delas. Sobre impactos — técnicos, financeiros, organizacionais. Sobre falhas — inclusive as que você não causou diretamente, mas poderia ter antecipado. Sobre resultados — não só os seus, mas os do time, do produto, do escopo da empresa.

Quanto mais sênior você é, menos o seu trabalho é "escrever código" e mais ele passa a ser decidir o que não escrever, o que simplificar, o que evitar. A empresa não te paga mais porque você escreve mais bonito. Ela paga porque sabe que você vai questionar o que não faz sentido, prever consequências — mesmo quando isso significa dizer "não" para uma ideia tecnicamente interessante, ou "ainda não" para uma feature que todo mundo quer.

Essa transição é difícil porque vai contra tudo que te trouxe até aqui. Você passou anos sendo recompensado por resolver problemas técnicos. Agora precisa ser recompensado por evitar que problemas existam. É um jogo diferente, com regras diferentes, e muita gente nunca percebe que as regras mudaram.

Fundamentos não são negociáveis — mas também não são troféu

Nada disso diminui a importância da base. Pelo contrário.

Fundamentos são linha de chegada. Não são opcionais. Errar no básico é um problema sério que se manifesta de formas previsíveis: processos que quebram em falhas que poderiam ter sido antecipadas, transações mal definidas que corrompem dados, ausência completa de pensamento em falha e escala, decisões técnicas desconectadas da realidade operacional.

Isso não é "estilo de código" ou "preferência pessoal". É falta de maturidade profissional. E a maturidade não vem do que você sabe — vem do que você consegue colocar em prática quando ninguém está olhando.

Mas — e esse é o ponto central de tudo — dominar o básico não é mérito. É obrigação. É o preço da entrada. É o que te permite participar da conversa, não o que te dá autoridade nela.

A pergunta que fica

Sênior não é quem usa termos em inglês. Não é quem posta threads bonitas. Não é quem domina o framework da moda.

Sênior é quem entrega valor de forma consistente, antecipa problemas antes que virem crise, entende o negócio tanto quanto entende tecnologia, e sabe quando técnica é solução e quando ser pragmático. Os conceitos citados ao longo desse texto — tratamento de erros, idempotência, circuit breakers — não são diferenciais. São o mínimo para estar no jogo.

O diferencial começa depois disso.

E talvez a reflexão mais importante não seja concordar ou discordar do que eu disse aqui. É sobre olhar honestamente para a própria trajetória e perguntar: estou crescendo de verdade ou apenas acumulando tempo? Estou desenvolvendo julgamento ou apenas colecionando conhecimento? Estou me preparando para o jogo que existe ou para o jogo que eu gostaria que existisse?

A resposta a essas perguntas não está em nenhum post do LinkedIn. Está no que você faz quando ninguém está olhando, nos problemas que você escolhe enfrentar, na distância entre o que você diz que sabe e o que você realmente consegue entregar.