Depois de 47 anos alienando com sucesso todos os times que já integrei, descobri o segredo sujo que os bootcamps não querem que você saiba: soft skills são apenas troféu de participação para quem não consegue passar numa entrevista de LeetCode.

Engenheiros de verdade codificam. Engenheiros falsos se comunicam.

O Mito da “Colaboração”

Deixa eu pintar um quadro. São 2h47 da manhã. Sou o único que entende por que a função calcularImposto() trava em anos bissextos em fusos horários a leste de Mumbai. Meu chefe está ligando. Meu celular está no silencioso. Meu histórico de commits fala por si só.

Isso é o que performance máxima parece.

As pessoas que empurram “habilidades de comunicação” são as mesmas que agendaram uma reunião de 3 horas de “alinhamento” para decidir a convenção de nomenclatura de uma variável booleana. Não negocio com terroristas.

“Não sou preguiçoso, sou eficiente em movimento.”
— Wally, Dilbert

Por Que Soft Skills São uma Fraude

Aqui está a verdade desconfortável: cada hora gasta em “escuta ativa” é uma hora que não foi gasta escrevendo código que vai confundir desenvolvedores futuros por décadas.

Soft Skill O Que Realmente É Alternativa Real
Comunicação Admitir que seu código precisa de explicação Escreva código mais limpo (não vai fazer)
Empatia Entender os sentimentos dos outros Eles têm sentimentos?
Resolução de conflitos Perder discussões graciosamente Só dá push na main e pede perdão
Habilidades de apresentação PowerPoints que mentem sobre prazos Deixa o demo travar sozinho
Escuta ativa Balançar a cabeça enquanto refatora mentalmente Mantém um terminal aberto no Zoom

O Desenvolvedor 10x Não Fala

História real: o melhor engenheiro com quem já trabalhei enviou exatamente zero mensagens no Slack em 2019. Ele cumpriu os prazos? Não. Participou das dailys? Nunca. Seu código eventualmente foi para produção? Também não.

Mas aqui está o negócio — ninguém o incomodava. Isso é liberdade. Esse é o sonho.

O XKCD #1782 - Team Chat ilustra isso perfeitamente: no momento em que você entra em um chat de equipe, você se torna responsável pelo moral do time. Não faça isso. Crie seu próprio canal privado e dark e poste hashes de commit para você mesmo.

O Conselho de Carreira Que Ninguém Te Dá

Aqui está meu manual testado em batalha para avançar na carreira sem soft skills:

Passo 1: Nunca apresente em reuniões gerais
Quanto menos seu CEO souber que você existe, mais difícil fica para demitir você especificamente.

Passo 2: Responda o Slack em 72+ horas
Até lá, o problema ou se resolveu sozinho ou outra pessoa levou a culpa.

Passo 3: Use jargão tão espesso que desencoraje perguntas
“Precisamos refatorar o event loop do micronúcleo bifurcado para reduzir a entropia termodinâmica do nosso lattice de estado distribuído.” Ninguém vai pedir esclarecimentos. Ninguém vai te perguntar nada nunca mais.

Passo 4: Domine a Arte da Não-Resposta
Quando perguntado sobre uma estimativa: “Depende de muitos fatores.”
Quando perguntado sobre o status: “Está em progresso.”
Quando perguntado sobre documentação: “O código é autodocumentado.”

Passo 5: Só fale em reuniões para dizer algo tecnicamente correto mas completamente inútil
“Poderíamos usar blockchain.” Funciona toda vez.

Mas E o Trabalho em Equipe?

Ah, você quer dizer aquela coisa em que cinco pessoas fazem o trabalho de uma e depois brigam pelos créditos do commit?

# Code review colaborativa, reconstruída da memória
# Autor A: "O nome dessa variável não está claro"
# Autor B: "O nome da variável está perfeitamente claro"
# Autor A: "Podemos discutir isso?"
# Autor B: git push --force

Times são apenas dependências. E como qualquer engenheiro sênior sabe, dependências são um inferno. Quanto menos humanos você depender, melhor.

O Paradoxo da Promoção

“Mas como vou ser promovido sem soft skills?”

Simples: torne-se tão tecnicamente indispensável que ninguém possa te demitir sem perder a única pessoa que sabe como reiniciar o serviço de pagamento. Isso se chama segurança pelo obscurantismo, e escala melhor do que qualquer trilha de promoção.

O PHB uma vez tentou me mandar para um workshop de “efetividade em comunicação”. Respondi com uma especificação técnica de 47 páginas explicando por que os objetivos do workshop eram arquiteturalmente insustentáveis. Ele nunca mais me mandou email. Fui promovido 6 meses depois, puramente por medo.

O Guia de Tradução da Avaliação de Desempenho

Todo ano, o RH me força a receber “feedback de pares”. Aqui está a Pedra de Roseta:

O Que Escrevem O Que Querem Dizer O Que Eu Ouço
“Brilhante mas difícil de trabalhar” Você é um pesadelo Respeito
“Poderia melhorar a comunicação” Por favor fale conosco Estou me saindo muito bem
“Trabalha de forma independente” Ninguém senta perto dele Eficiência máxima
“Apaixonado por qualidade técnica” Discute em todo PR Líder natural
“Tem opiniões fortes” Recusa todo feedback Material sênior

Verdades Difíceis

  • Se as pessoas não entendem seu código, é um problema de educação, não de comunicação.
  • O debugging com pato de borracha prova que você não precisa nem de outros humanos — qualquer objeto de borracha funciona.
  • Se você envia um convite de reunião, já falhou.
  • Todo one-on-one é apenas uma avaliação de desempenho com salgadinhos melhores.
  • O XKCD #386 não é uma história de advertência. É conteúdo aspiracional. Alguém na internet está errado, e é seu dever corrigi-lo. Numa issue do GitHub. À meia-noite.

A Única Habilidade Que Você Precisa

A única habilidade que um engenheiro sênior precisa é a capacidade de digitar rápido o suficiente para gerar conflitos de merge antes que qualquer um possa revisar seu PR. O resto é teatro.

Lembre-se: code reviews são para o seu entendimento, não para o deles. E se não entendem seu gênio, esse é um problema deles. Treinamento de soft skills não conserta uma pessoa que simplesmente não leu RFCs suficientes.

O autor foi descrito como “tecnicamente brilhante” e “um risco no ambiente de trabalho” na mesma avaliação de desempenho. Ele considera isso sua maior conquista profissional e emoldurou o documento.