"O código funciona" é o mínimo, não o padrão. A verdadeira maturidade de engenharia é sobre como alguém lida com escopo, ambiguidade e pessoas, não apenas se sua funcionalidade funciona. A definição mais simples que uso: um engenheiro está crescendo quando consegue lidar com problemas maiores com menos orientação.
| Sinal | Menos maduro | Mais maduro |
|---|---|---|
| Tamanho do problema | Precisa de tarefas bem definidas | Assume problemas abertos |
| Orientação | Precisa de direcionamento | Opera independentemente |
| "Pronto" | Código faz merge | Resultado entregue e assumido |
| Raio de explosão | Seu próprio trabalho | A eficácia do time |
Dois engenheiros entregam uma funcionalidade. Um fecha o ticket. O outro sinaliza um caso extremo arriscado para o PM, adiciona monitoramento e escreve um documento curto para que a próxima pessoa não se perca. Mesmo código entregue, maturidade muito diferente, e é o segundo comportamento que estou promovendo.
Se você apenas medir se o código funciona, recompensa o output e perde as coisas que realmente se acumulam: julgamento, propriedade e elevação de outros. Nomear esses critérios explicitamente dá aos engenheiros um mapa claro do que "crescimento" significa, e oferece a você uma base justa e consistente para feedback e promoção.