O pior tipo de programador
Arquiteturas sobreengenheiradas, desenvolvedores “rockstar” e escolhas de tecnologia guiadas por buzzwords são apontados como causas de sistemas frágeis e difíceis de manter, mas muitos argumentam que a raiz do problema é liderança de engenharia e processo fracos, e não personalidades ou linguagens individuais. Comentadores contrastam programadores hiperambiciosos, que otimizam para currículo e heroísmos, com engenheiros “sem glamour”, defensivos, que entregam código simples e estável que outros conseguem manter, observando que a gestão muitas vezes recompensa os primeiros. O debate se estende às escolhas de linguagem e ferramentas (Rust vs Go, FP em Java, frameworks pesados) e a se as equipes devem favorecer stacks expressivas e complexas ou tecnologias deliberadamente sem glamour e amplamente compreendidas para reduzir risco e melhorar a colaboração.
Causa raiz: gestão, não “programadores ruins”
- Muitos argumentam que o problema real é a falta de liderança técnica ou processos fracos.
- A gestão não técnica frequentemente define prazos e direção técnica sem entender os trade-offs.
- Permitir que dois “magos” construam sozinhos a arquitetura central, sem revisões ou demos iniciais, é visto como uma falha de gestão.
- Estruturas de incentivo (promoção ligada a truques chamativos com frameworks, “ser arquiteto”) podem ativamente encorajar comportamento prejudicial.
Sobreengenharia e escolhas técnicas
- Há amplo consenso de que construir arquiteturas complexas e genéricas antes de requisitos claros é arriscado.
- Vários relatos: apps CRUD com Angular/Spring excessivamente sobreengenheirados; protocolos customizados em cima de RabbitMQ; “Java escrito como Haskell” causando problemas de desempenho e estabilidade.
- Alguns enfatizam TDD / prototipagem iterativa e extrair a arquitetura de código funcionando, em vez de “astronautagem de arquitetura” antecipada.
Mentalidade rockstar / 10x e incentivos
- São comuns os “alto desempenho” que entregam muito código complexo, monopolizam o conhecimento e depois saem.
- A gestão muitas vezes recompensa ocupação visível, linhas de código e volume de tickets, não a manutenibilidade de longo prazo.
- Outros rebatem que esses “rockstars” muitas vezes realmente entregam mais, e culpá-los pode mascarar as falhas de colegas de baixo impacto e da gestão.
Dinâmica de equipe, fator-bus e código sem glamour
- Há forte apoio a código “sem glamour”, defensivo e fácil de entender, mesmo que seja mais lento para escrever.
- O sucesso da equipe exige documentação, mentoria, revisões de código e propriedade compartilhada; heroísmo individual cria um baixo fator-bus.
- Vários observam que o desenvolvimento real em equipe é mais lento e mais comunicativo, mas produz sistemas mantíveis.
Debates sobre linguagem e stack (Go, Rust, FP, etc.)
- Alguns concordam que certas linguagens (Rust, Scala) e conjuntos poderosos de recursos podem atrair “esperteza pela esperteza” e código no estilo DSL.
- Outros discordam fortemente de afirmações amplas como “equipes Go prosperam, equipes Rust enferrujam”, citando projetos bem-sucedidos em Rust e decisões de design questionáveis em Go.
- Consenso: o risco real é usar mal as ferramentas, forçar paradigmas em linguagens incompatíveis ou escolher stacks que a equipe não consegue manter coletivamente.
Simplicidade vs anti-intelectualismo
- Muitos defendem “linguagens simples e tecnologia sem glamour” para apps CRUD/de negócio.
- Outros veem o artigo e partes da discussão como descambando para anti-intelectualismo, descartando paixão, técnicas avançadas ou linguagens expressivas.
- O equilíbrio sugerido: otimizar para simplicidade e compreensão da equipe, mas não proibir ferramentas avançadas quando elas claramente resolvem problemas reais.