- Em grandes empresas de tecnologia, o curto tempo de permanência e as frequentes reorganizações fazem com que muitos engenheiros trabalhem em codebases com as quais não estão familiarizados
- Na prática, uma parte significativa das mudanças de código é feita por engenheiros em nível de “iniciante” com menos de 6 meses de casa
- Alguns engenheiros experientes, os “old hands”, compensam parte da qualidade, mas encontram limites por causa da sobrecarga de trabalho e de responsabilidades informais
- As empresas priorizam mobilidade da força de trabalho e visibilidade interna (legibility) acima da especialização, e isso é o custo de uma piora de qualidade deliberadamente aceita
- No fim, independentemente da capacidade individual de cada engenheiro, a causa fundamental do código ruim é um problema estrutural: trabalhar com foco em entregas rápidas dentro de sistemas desconhecidos
A estrutura que produz código ruim em grandes empresas
- Grandes empresas de tecnologia contratam engenheiros talentosos com salários altos, mas muitas vezes o tempo de permanência fica em apenas 1 a 2 anos
- A estrutura de remuneração faz com que a compensação em ações (share grant) seja totalmente adquirida após 4 anos, e depois disso o salário efetivo caia pela metade
- Existem alguns refreshers anuais (refresh), mas eles não são garantidos, o que leva engenheiros a trocar de emprego
- Mesmo contando mobilidade interna, é raro alguém ficar mais de 3 anos na mesma codebase
- Reorganizações (re-org) acontecem todo ano, ou até com mais frequência
- Em contrapartida, codebases costumam ser mantidas por mais de 10 anos, então a maioria dos engenheiros está sempre “aprendendo” um sistema novo
- Como resultado, uma parte significativa das mudanças no código é feita por iniciantes com menos de 6 meses de empresa
O papel e os limites dos “old hands”
- Alguns engenheiros permanecem por muito tempo em um sistema específico e desenvolvem especialização profunda
- Eles conseguem identificar problemas cedo por meio de code review
- Porém, essa estrutura é informal e não institucionalizada
- As empresas têm pouco interesse em preservar especialização de longo prazo e muitas vezes movem engenheiros experientes para outros times
- Os experientes vivem constantemente sobrecarregados
- Falta tempo para revisar pessoalmente todas as mudanças
- Se o desempenho nas próprias entregas cair, eles ainda correm o risco de serem prejudicados
A realidade do engenheiro produtivo mediano
- O engenheiro produtivo mediano em uma grande empresa costuma ter as seguintes características
- É competente o bastante para passar pelo processo seletivo, mas não domina uma nova codebase ou linguagem
- Trabalha tentando cumprir prazos sobrepostos de vários projetos ao mesmo tempo
- Como resultado, faz o melhor que pode em um ambiente orientado mais por cronograma do que por qualidade
- Ex.: um engenheiro iniciante corrige de forma improvisada um bug em um código desconhecido, um engenheiro experiente faz uma revisão rápida e o código é colocado em produção
- Anos depois, esse código reaparece e surge a pergunta: “por que isso foi escrito assim?”
Por que as empresas mantêm essa estrutura
- Grandes empresas valorizam mais a visibilidade interna (legibility) do que a produtividade
- Preferem estruturas em que seja possível saber quem está fazendo o quê e realocar pessoas a qualquer momento
- Isso representa uma escolha deliberada de sacrificar especialização e qualidade de código
- Aceita-se a perda de conhecimento para ganhar flexibilidade e remanejar pessoas rapidamente quando surgem problemas
- Em especial num contexto em que mudanças rápidas de direção (pivot) para novas áreas, como IA, se tornaram importantes, essa estratégia funciona a favor das empresas
- Mas, nesse ambiente, é inevitável haver muitos engenheiros trabalhando às pressas em sistemas desconhecidos
Os limites individuais dos engenheiros e a engenharia “pura/impura”
- Engenheiros individualmente não têm poder para mudar essa estrutura
- Em 2025, o centro do poder já se deslocou dos engenheiros para a gestão
- O melhor que uma pessoa pode fazer é se tornar um “old hand” em uma área específica e preservar um nível mínimo de qualidade
- Porém, intervir demais pode até aumentar o risco de ser colocado em PIP por baixa performance
- O texto apresenta a distinção entre engenharia “pura” (pure) e “impura” (impure)
- Engenharia pura: centrada em projetos técnicos independentes, como o desenvolvimento de linguagens de programação
- Engenharia impura: o ambiente realista de trabalhar com foco em prazos dentro de sistemas desconhecidos
- A maioria dos engenheiros em grandes empresas está na engenharia impura, e nesse caso código ruim é um subproduto inevitável
- Se o sistema funcionar bem o suficiente, o projeto é considerado um sucesso
Conclusão: a “codebase desconhecida” como causa estrutural
- Grandes empresas têm o poder de mover engenheiros livremente, e isso é uma escolha corporativa que aceita a perda de especialização
- A responsabilidade pelo código ruim não está no indivíduo, mas sim na estrutura organizacional e na forma de alocação de pessoas
- Mesmo que a capacidade de todos os engenheiros dobrasse, erros em codebases desconhecidas continuariam acontecendo
- A causa raiz é a estrutura em que “a maioria dos engenheiros precisa fazer a maior parte do trabalho em código com o qual não está familiarizada”
- Apontar exemplos de código ruim ajuda a melhorar, mas o alvo da crítica não deve ser o engenheiro, e sim o sistema
5 comentários
Pela minha experiência, se a base em CS, especialmente em PLT, for sólida, no fim a pessoa escreve código relativamente melhor em qualquer ambiente.
Mesmo sem um conhecimento tão extraordinário, se a pessoa pelo menos entende os princípios mais básicos, com tempo suficiente e num código com o qual esteja familiarizada, ela consegue produzir uma certa qualidade de código. Se fizer
nrefatorações, até se a IA escrever, o resultado acaba ficando minimamente convincente.Por mais tempo que se passe em cima de um único código-fonte, também há muita gente com 20 anos de carreira que só sabe produzir espaguete e nem entende por que não deveria fazer isso.
A menos que seja possível ter um ambiente perfeito com tempo e orçamento infinitos, isso me soa como um conteúdo vazio, sem grande significado. Em qualquer época e em qualquer função, isso não é sempre a mesma coisa?
Escrever código melhor dentro do mesmo sistema é claramente, sim, uma capacidade do engenheiro.
Seria ótimo se os sistemas fossem projetados com folga e flexibilidade para conseguirem oferecer boa qualidade. E, sem dúvida, em média isso deve ser mais verdade hoje do que em épocas em que a engenharia organizacional e as metodologias de desenvolvimento eram menos avançadas do que agora.
Ainda assim, aos meus olhos, isso soa como alguém cujo ego como engenheiro é inflado, mas cujo senso de responsabilidade como membro da organização é fraco, tentando justificar que nada disso é culpa sua, e sim erro da diretoria.
Engenheiros civis, designers industriais e animadores não têm prazo de entrega, e são avaliados apenas por criatividade e qualidade, não por produtividade, enquanto só os programadores é que têm prazo?
Tem um monte de baboseira aí... esse papo de código ruim ou código bom é coisa que júnior fica discutindo, e o mais importante é: existe ou não existe um sênior que saiba fazer bem o design de software adequado para aquele setor?
Os textos postados aqui podem estar em um ambiente um pouco diferente de algumas perspectivas ou experiências do mercado nacional de SI, que em geral até ignoram o OCP.
De qualquer forma, Linus Torvalds não é júnior, né...
Opiniões do Hacker News
Já li os textos dessa pessoa várias vezes, e sempre ficava uma sensação incômoda
Agora acho que entendi o motivo. A análise em si é lógica, mas por baixo parece haver uma espécie de niilismo
Talvez seja alguém que já foi idealista, mas que, por más experiências, tenta explicar que “acreditar em alguma coisa é inútil”
Por isso surgem perguntas como estas — por que as grandes empresas precisam agir assim, por que código ruim atormenta os engenheiros, será que esse sentimento é mesmo errado, ou a culpa é da estrutura econômica em que vivemos, ou será que se conformar com forças gigantescas é maturidade?
Porque eu tenho responsabilidade pelo resultado.
O cronograma atrasa porque preciso consertar o código bagunçado que outra pessoa fez, e por causa disso minha avaliação no fim do ano piora
Perguntam “por que isso levou tanto tempo?”, mas foi porque tive que fuçar um monte de lixo para encontrar o problema
Tentei durante anos fazer a gerência entender esse tipo de problema, mas no fim parecia um trabalho de Sísifo
Assim como um arquiteto se incomoda ao ver um prédio malfeito, ou um diretor sofre ao ver um filme mal executado, um bom engenheiro busca qualidade de acabamento
Acho que maturidade não é se conformar com a impotência, mas lutar o máximo possível
Curiosamente, chamam o autor de niilista, mas a própria ideia de que “o mundo está fora de controle” já é niilista
Antes eu também achava que, se não fosse perfeito, era código ruim, mas passei por várias empresas e minha visão mudou
Agora acho que, se atende aos objetivos de negócio e passa de um patamar básico de qualidade, está bom
No fim, quase todo código sempre tem espaço para melhoria
Me identifiquei porque ele descreve exatamente a realidade fria da engenharia Staff+
A ideia de “faça o que a empresa quer, mesmo que não seja o certo” é cínica, mas ainda me parece melhor do que ser triturado pelas engrenagens da empresa
Ele só não acredita nos seus ideais, e isso não faz dele necessariamente um niilista
Acho que o problema não é tempo de casa, mas motivação
Isso lembra a fala do filme Office Space: “se trabalhar duro não traz recompensa, a motivação não aparece”
Mas a gerência valoriza mais resultado do que bom código
Como não conseguem medir o valor da manutenção, esse trabalho não é reconhecido
No fim, quem sobe na carreira é quem colocou código porco em produção
Eu me importava com o time e com o código e trabalhava com cuidado, mas no fim era avaliado por métricas simples como quantidade de PRs
A dificuldade do código e a contribuição para o time eram ignoradas, e só importavam os “números visíveis”
Ironicamente, o gerente que me avaliava foi demitido alguns meses depois
Ironicamente, se eu não me importasse, não teria me machucado com isso
Grandes empresas tratam engenheiros como recursos substituíveis
Isso não é só uma questão de eficiência, mas uma estratégia para inclinar o equilíbrio de poder para o lado da gerência
A intenção é evitar que projetos centrais dependam de um grupo específico de engenheiros
Quer que todo trabalhador seja substituível
Pelo contrário, muitas vezes ela tenta reter bons engenheiros
Ou seja, essa cultura não é um problema só da gerência
Vejo com frequência casos em que a sintaxe e a estrutura do código são de manual, mas a abordagem fundamental está errada
Code review foca só na sintaxe, e não se discute o problema de negócio nem a complexidade
No curto prazo parece aceitável, mas no longo prazo a dívida técnica explode
Como resultado, discussões triviais sobre qualidade de código atrasam PRs por dias
Todo mundo fica obcecado só com a limpeza superficial do código
É difícil avaliar a solidez lógica ou enxergar o quadro geral, e muitas vezes o revisor nem conhece o contexto
Se a organização como um todo não tem margem para absorver esse tipo de feedback, no fim ela passa a depender de “sistemas que meio que funcionam”
O design maior deveria ter sido revisado antes do code review
Estamos, basicamente, automatizando custos de longo prazo
Grandes empresas não se importam com o código em si
O código é apenas o meio pelo qual a empresa opera
No fim, o importante não é o código, mas o processo
O ponto central é se existem procedimentos para recuperar o sistema quando ele quebra
Toda indústria, quando cresce, faz concessões parecidas
Em vez da perfeição, o lucro vem de uma qualidade “boa o suficiente”
Como na diferença entre uma cadeira da IKEA e uma da Herman Miller, a questão são as restrições diferentes
A verdadeira habilidade é saber onde fazer concessões
A estrutura das grandes empresas força esse tipo de concessão sobre os engenheiros
Bons engenheiros seniores não escrevem código ruim desde o começo
O problema é a pressão por resultado no curto prazo e a falta de base
Pular review ou não pensar arquitetura o suficiente é a verdadeira causa
Como descrito neste comentário, em cima de milhões de linhas de hacks acumulados, por mais que você tente, não dá para deixar limpo
No fim, é como levantar um prato inteiro de espaguete
O sênior está sempre preso ao dilema entre “fazer direito” e “terminar rápido”
Ninguém entende um codebase complexo da noite para o dia, e se a organização não valoriza acúmulo de conhecimento, a qualidade piora
É bom dar a funcionários novos tarefas de documentação e organização para que aprendam a estrutura do código
Mesmo com muito código legado cheio de gambiarra, não dá para mexer porque não pode quebrar
Não importa quão bom seja o design: se a base é areia, tudo desaba
A conclusão do autor de que “legibilidade vem antes de qualidade” implicaria que todo projeto de grande empresa deveria obrigatoriamente usar ferramentas de análise estática e formatadores automáticos
Mas na prática não é assim
A adoção dessas ferramentas depende de decisão de gestores não técnicos, e eles odeiam custo de curto prazo
No fim, o prazo de entrega atropela tudo
Quando eu fazia consultoria para uma grande fabricante, havia por todo o código uns padrões estranhos de modelagem de objetos
Investigando a causa, descobri que o time de desenvolvimento tinha entendido completamente errado o conceito pretendido pelo designer (blueprint–molde–produto)
Sugeri corrigir, mas a resposta foi: “já é tarde demais”
Como resultado, o modelo errado permaneceu por mais de 10 anos, gerando uma dívida técnica enorme
A estatística de baixa permanência em grandes empresas pode ser enganosa
É só efeito do crescimento acelerado do quadro, que encurta a mediana
Na prática, o jeito certo é olhar para quem saiu da empresa
Simplesmente porque no passado havia menos desenvolvedores no total