O segredo do engenheiro que vale o salário: a habilidade de transformar o que você não sabe (`Ambiguity`) em algo que dá para fazer
(terriblesoftware.org)Pontos principais:
- A diferença decisiva entre engenheiros sênior e de nível pleno está na capacidade de tornar concretos problemas incertos e ambíguos.
- O valor de um sênior não vem da habilidade de programar em si, mas de remover os riscos do projeto e transformá-los em um plano executável.
- As práticas atuais de contratação (como testes de algoritmo) falham em avaliar essa capacidade.
- O crescimento real começa com a prática de definir o problema com clareza antes da etapa de codificação.
Introdução: repensando a definição de engenheiro sênior
- Em geral, engenheiros sênior são definidos por uma lista variada de habilidades, como design de arquitetura, comunicação e liderança.
- No entanto, deixando de lado cargo, salário e anos de experiência, existe uma única habilidade central que distingue engenheiros acima do nível sênior: a capacidade de reduzir a ambiguidade.
- Todas as outras competências (como execução técnica) são resultados derivados dessa habilidade central.
Desenvolvimento
1. A diferença na forma de resolver problemas: clareza vs. ambiguidade
- Engenheiro pleno (Mid-level): tem ótimo desempenho quando recebe uma especificação clara (
Spec) e restrições definidas. É habilidoso para resolver problemas bem definidos. - Engenheiro sênior: se diferencia quando recebe demandas vagas e abstratas, como "precisamos melhorar a performance", "as reclamações dos usuários estão aumentando" ou "precisamos considerar escalabilidade".
- O sênior não apenas executa um problema ambíguo; ele o analisa, o desmonta e o transforma em tarefas concretas.
2. O papel central do sênior é remover riscos do projeto
-
Diante de um problema grande e abstrato, o engenheiro sênior reduz a incerteza com abordagens como:
-
Fazer perguntas essenciais que os outros não fazem.
-
Separar os sinais importantes do ruído (
Noise). -
Definir prioridades entre o que deve ser feito agora e o que pode ser adiado.
-
Esse processo reduz o risco do projeto (
De-risking) e organiza o estado de "não sabemos exatamente o que é isso" em "pequenos projetos executáveis e elementos a eliminar". -
Quando um sênior faz isso bem, o projeto avança de forma suave e, por fora, parece fácil — mas isso é resultado de uma enorme quantidade de "trabalho invisível" feita antecipadamente.
3. Abordagens concretas para reduzir a ambiguidade
- Antes de programar, o engenheiro sênior faz perguntas como estas para esclarecer o problema:
- A essência do problema: qual é o problema fundamental real que estamos tentando resolver, e não a solução que achamos que queremos?
- Definição de usuário: de quem exatamente é a dor que estamos tentando resolver, e qual dor? (evitar a palavra genérica "usuário")
- Validação de premissas: quais premissas erradas podem estar escondidas no plano atual?
- Avaliação de risco: qual é o pior cenário possível se nosso julgamento estiver errado?
4. Os limites do sistema de contratação e a seleção equivocada de sêniores
- A maioria das empresas conduz a contratação focando em listas de tech stack ou na capacidade de resolver problemas de algoritmo (
LeetCode). - Esse tipo de abordagem não valida a capacidade de transformar requisitos de produto ambíguos em um plano executável.
- Como resultado, são produzidos engenheiros "sênior só no nome": pessoas com ótima habilidade de programação, mas incapazes de agir diante de especificações incompletas.
Conclusão: uma recomendação para crescer
- Habilidades de arquitetura e comunicação também são importantes, mas só passam a ter valor depois que "o que construir" já está claro.
- Excelência técnica sem reduzir a ambiguidade não passa de "resolver o problema errado com elegância".
- O critério para saber se você está em nível sênior é se, ao receber uma tarefa abstrata, você espera que outra pessoa a esclareça ou se você mesmo a torna concreta para que o time possa executar.
- Isso não é um talento inato, mas algo que se desenvolve com prática; por isso, ao receber um ticket ambíguo, em vez de começar a programar imediatamente, você deve começar a treinar a concretização do problema.
5 comentários
Também acho que avaliar um desenvolvedor sênior por meio de um "teste de código de algoritmos" é... uma limitação do sistema de contratação. Acho que um desenvolvedor sênior que faz valer o salário é alguém que se aproximou da essência do problema, ou que consegue se aproximar dela.
Aprendo neste texto que isso varia bastante conforme a perspectiva de cada um. Pelo meu critério, acho que o que distingue um engenheiro sênior de um engenheiro de nível intermediário é apenas o escopo.
Transformar
Ambiguityem algo concreto é uma competência básica de um engenheiro, e me parece que, a partir do nível intermediário, a pessoa já precisa ser capaz de fazer isso para que o título de engenheiro seja adequado. Então, para mim, este texto pode servir como um critério para diferenciar um engenheiro de nível intermediário de um engenheiro iniciante (associate).A excelência técnica, quando o problema não foi claramente definido,
não passa de "resolver com elegância o problema errado".
Uma frase realmente arrepiante
Em teste para desenvolvedor sênior, até dá para entender ter teste de programação,
mas quando passam problema de algoritmo acho absurdo demais (fiquei tão sem reação que nem lembro).
1. A técnica de fazer perguntas e o capital social (Social Capital)
2. Autonomia e gestão de risco (Autonomy & Risk)
3. Inflação de títulos e a contradição estrutural da contratação
4. Tempo de carreira (Tenure) vs. prática deliberada
If), enquanto o sênior considera e se prepara para o caso de as condições mudarem (What-if).5. Visão cética sobre o título de sênior