A pergunta mais comum na mentoria é uma variação de “o que eu preciso estudar pra virar pleno?”. Quem faz a pergunta espera uma lista de tecnologias.
Nunca é a lista. Já vi júnior que sabia mais framework que gente pleno do mesmo time, e continuava júnior na régua que importa.
O que separa os dois na prática
Júnior entrega código que funciona. Pleno entrega código que funciona e que ele consegue explicar.
Parece pouca diferença. É enorme.
“Funciona” pode ser resultado de tentativa e erro. Copia do Stack Overflow, ajusta até o teste passar, abre o PR. O código está certo e a pessoa não sabe por quê. Isso dá pra fazer por anos, e é um teto muito baixo, porque no dia em que quebra de um jeito novo não tem de onde puxar.
“Consigo explicar” quer dizer que existe um modelo mental por trás. Você sabe o que aquela linha faz, por que escolheu ela e o que aconteceria se tivesse escolhido a outra.
Os três sinais que eu procuro
Investigação com método. Júnior travado tenta coisas. Muda uma linha, roda, muda outra, roda. Pleno travado forma uma hipótese, pensa em como testá-la, testa, e elimina metade do espaço de busca a cada passo.
A diferença aparece no tempo: um bug que leva três dias no primeiro modo leva duas horas no segundo. E não é inteligência, é método. Método se aprende, e se aprende rápido quando alguém aponta.
Estimativa que se sustenta. “Fica pronto amanhã” dito com convicção e entregue em seis dias é o padrão de quem ainda não aprendeu a enxergar o que não fez parte da tarefa. Migração, teste, revisão, deploy, o campo que faltou no formulário.
Pleno erra estimativa também. A diferença é que ele avisa no segundo dia, não no sexto.
Decisão defendida. Numa revisão de código, quando alguém questiona uma escolha, júnior muda. Pleno explica por que fez assim, ouve o argumento contrário, e às vezes muda. A concordância imediata parece humildade e costuma ser ausência de razão.
O que ninguém fala
Boa parte do salto acontece fora do editor.
Dizer “isso não vai dar no prazo” na reunião, e não no privado depois que já atrasou. Perguntar “por que a gente está fazendo isso?” antes de estimar. Discordar do time inteiro com dado na mão.
Isso não é habilidade social genérica. É a capacidade de sustentar uma posição técnica na frente de gente que decide. Sem ela, você fica sendo executor de escopo alheio, independente da qualidade do seu código.
O caminho mais rápido que eu conheço
Um projeto que você mantém por meses.
Não doze exercícios, não um tutorial por semana. Um sistema seu, que você constrói, coloca no ar, mexe de novo dois meses depois e sente na pele o que o você do passado deixou de errado.
É a única coisa que ensina manutenção, e manutenção é o que separa código que funciona de código que serve. Enquanto você só constrói do zero, tudo parece limpo, porque nada ainda apodreceu.
Some a isso alguém sênior olhando o que você escreveu e perguntando por que você fez daquele jeito. Não corrigindo: perguntando. A pergunta obriga a formular o raciocínio, e formular o raciocínio é o mecanismo inteiro.
Como saber que chegou
Não é o título, e não é o tempo de casa.
É quando as pessoas começam a te procurar antes de decidir, em vez de depois de quebrar. É quando você abre um PR e sabe, antes da revisão, quais dois pontos vão ser questionados. É quando o seu palpite sobre onde está o bug acerta na maior parte das vezes.
Esse último é interessante porque é impossível fingir. Palpite calibrado é modelo mental funcionando.
Sobre pressa
O mercado empurra pra correr. Título pleno em um ano, sênior em três, tech lead em quatro.
O problema de pular etapa é que o buraco não fecha sozinho, e ele aparece exatamente no pior momento: quando você é o sênior da sala e alguém faz a pergunta que você deveria saber responder desde o começo.
A parte técnica te faz entrar. A parte difícil te faz ficar.
É exatamente esse salto que eu trabalho na mentoria 1:1: doze semanas, um projeto âncora, e alguém lendo o seu código toda semana.