- Na cultura de engenharia de software, continua existindo uma estrutura em que quem cria sistemas complexos recebe mais reconhecimento, enquanto quem escolhe soluções simples acaba não sendo valorizado
- Em avaliações de promoção, entrevistas e revisões de design, a complexidade costuma ser confundida com “impacto”, reforçando a tendência de adicionar abstrações e escalabilidade desnecessárias
- Implementações simples acabam como “resultados invisíveis”, enquanto estruturas complexas são mais fáceis de transformar em narrativas vistosas e documentação para preencher materiais de promoção
- A verdadeira senioridade não está em usar mais ferramentas, mas em ter discernimento e confiança para saber quando excluir a complexidade
- Tanto engenheiros quanto líderes precisam tornar a simplicidade visível e criar sistemas formais de avaliação e recompensa que a reconheçam
Simplicidade vs. complexidade: a assimetria da narrativa de promoção
- Exemplo de dois engenheiros do mesmo time: o Engineer A lançou uma funcionalidade em poucos dias com 50 linhas de código concisas; o Engineer B levou 3 semanas introduzindo uma nova camada de abstração, um sistema pub/sub e um framework de configuração
- O trabalho do Engineer B pode ser descrito no pacote de promoção como “projeto de uma arquitetura escalável orientada a eventos, introdução de uma camada de abstração reutilizável e construção de um framework de configuração”
- O trabalho do Engineer A pode ser expresso em apenas três palavras: “implementou a funcionalidade X”
- Na prática, foi um trabalho melhor, mas por ter sido feito para parecer simples, virou uma contribuição invisível
- Ninguém é promovido pela “complexidade evitada” — a complexidade parece inteligente porque os sistemas de avaliação foram montados para recompensá-la
Como entrevistas e revisões de design reforçam a complexidade
- Em entrevistas de system design, se você propõe uma solução simples (um único banco de dados, uma API direta, uma camada de cache), o entrevistador pressiona com “e se chegarem 10 milhões de usuários?”
- Quanto mais você adiciona serviços, filas e sharding, mais parece satisfazer o entrevistador
- A lição que o candidato aprende é: “uma resposta simples não foi suficiente”
- Pode haver motivos razoáveis para essa pressão do entrevistador (avaliar raciocínio sob pressão e entendimento de sistemas distribuídos), mas a mensagem que chega ao candidato é que “complexidade impressiona”
- Em revisões de design, repete-se o padrão de adicionar camadas e abstrações desnecessárias diante da pergunta “não deveríamos preparar isso para o futuro (future-proof)?”
- Não porque o problema exija isso, mas porque é o que a sala espera
- Há muitos casos em que uma abstração criada para evitar algumas linhas duplicadas de código acaba dificultando o entendimento e a manutenção
- O código parecia mais “profissional”, mas o usuário não recebeu a funcionalidade mais rápido, e o próximo engenheiro gastou metade do dia só para entender a abstração antes de fazer qualquer mudança
Complexidade adequada vs. complexidade desnecessária (Unearned Complexity)
- A complexidade em si não é o problema — para processar milhões de transações, é preciso um sistema distribuído; se 10 equipes constroem o mesmo produto, limites de serviço são necessários
- O problema é a complexidade desnecessária: a diferença entre “precisamos de sharding porque chegamos ao limite do banco de dados” e “vamos fazer sharding agora porque talvez cheguemos ao limite daqui a 3 anos”
- O código e a arquitetura de quem entende isso passam uma sensação de “claro, faz sentido”; não parecem mágicos nem brilhantes demais, mas também não fazem você se sentir tolo por não entender
- O caminho real para a senioridade não é aprender mais ferramentas e padrões, e sim saber quando não usá-los — qualquer um consegue adicionar complexidade, mas removê-la exige experiência e confiança
O que engenheiros podem fazer na prática
- É preciso tornar a simplicidade visível — o trabalho não fala por si, porque os sistemas de avaliação não foram desenhados para escutá-lo
- Em vez de “implementou a funcionalidade X”, descreva como “avaliou três abordagens, incluindo uma arquitetura orientada a eventos e uma camada de abstração customizada, concluiu que uma implementação simples atendia às necessidades atuais e previstas, lançou em 2 dias e operou sem incidentes por 6 meses”
- Decidir não construir algo também é uma decisão, e uma decisão importante — isso precisa ser documentado como tal
- Em revisões de design, em vez de simplesmente ceder à pergunta “não deveríamos preparar isso para o futuro?”, apresente: “para adicionar isso depois, levaríamos X; para adicionar agora, o custo seria Y; é melhor esperar”
- Não é uma refutação, e sim uma forma de mostrar que a análise já foi feita
- Converse diretamente com seu gerente: “quero que a forma como documento meu trabalho reflita não só o código, mas também as decisões que tomei” — do ponto de vista do gerente, isso também fornece a linguagem necessária para te defender
- Se, mesmo com tudo isso, o time só promove quem constrói os sistemas mais sofisticados, isso também é uma informação útil — algumas organizações realmente valorizam a simplicidade, enquanto outras só dizem isso e recompensam o oposto
O que líderes de engenharia podem fazer na prática
- Definir incentivos é responsabilidade da liderança — a maioria dos critérios de promoção é desenhada para recompensar complexidade, e “impacto” tende a ser medido pelo tamanho e escopo do que foi construído
- A avaliação deve incluir não só o que foi construído, mas também o que foi evitado
- Em revisões de design, em vez de perguntar “você considerou escalabilidade?”, mude para “qual é a versão mais simples que podemos lançar, e quais sinais concretos indicariam que algo mais complexo passou a ser necessário?”
- Essa única pergunta muda o jogo: faz da simplicidade o padrão e coloca sobre a complexidade o ônus da prova
- Em discussões de promoção, diante de um pacote formado por uma lista de sistemas impressionantes, é preciso perguntar: “isso tudo era realmente necessário? o sistema pub/sub era mesmo necessário, ou só ficou bonito no documento?”
- Quando um membro do time lança algo limpo e simples, é preciso ajudá-lo a construir a narrativa — para que “avaliou várias abordagens e escolheu a mais simples que resolvia o problema” vire um caso convincente de promoção, a liderança precisa tratá-lo dessa forma na prática
- É preciso prestar atenção em quem recebe parabéns publicamente nos canais do time — se só projetos grandes e complexos são elogiados, as pessoas vão se otimizar para isso
- É preciso reconhecer o engenheiro que apagou código e aquele que disse “ainda não precisamos disso” e estava certo
10 comentários
design orientado ao currículo...
Não acho que as sugestões deste texto sejam sem sentido, mas acho que é difícil demais vencer o "grande design". Afinal, o lado de lá é fácil demais, demais de explicar :(
Opiniões do Hacker News
Em uma pergunta de entrevista, apresentaram a situação de duas pessoas trocando uma planilha por e-mail
Eu respondi que migraria para o Google Sheets, mas parece que o entrevistador queria que eu projetasse a ferramenta por conta própria
Na época foi estranho, e até hoje não sei bem que lição deveria tirar disso
Ele deveria reconhecer uma boa resposta e, depois, conduzir com algo como: “isto é um cenário hipotético para avaliar design técnico, então vamos projetar um sistema novo”
Se o candidato não conseguir entrar nessa premissa, isso pode ser avaliado como outro sinal
Eu perguntaria: “quer que eu assuma que não existe uma solução pronta e desenhe algo do zero?”
Isso é como uma versão de design de sistemas das discussões de algoritmo em que o entrevistador só quer ouvir a resposta que ele espera
Na prática, era a decisão correta, mas Patrick Collison ligou pessoalmente e perguntou: “você não passou na entrevista, mas entende qual era a intenção?”
No fim, ele refez a entrevista e passou
Foi uma história que mostrou como é importante entender o objetivo da entrevista
Uma grande empresa de balsas gerencia posição de embarcações e alocação de funcionários com Google Sheets, e meu amigo dizia: “isso não é coisa que uma empresa grande deveria fazer”
Mas eu acho ótimo terem resolvido o problema com uma ferramenta já validada
Isso permite operar sem time interno de desenvolvimento nem terceirização cara
Foi uma experiência que me fez enterrar fundo minha arrogância
Depois que a outra pessoa explicar concretamente o que não está funcionando, aí sim começar o desenho técnico
Pode haver vários motivos para não usar Sheets — limitação de funcionalidade, restrição de acesso na China, política da empresa, problema de rede etc.
O cliente pode já querer uma solução customizada justamente por esses motivos
Ou seja, o papel do desenvolvedor não é simplesmente dizer “use Google Sheets”, mas entender o contexto do cliente
Ferramentas de IA para programação estão piorando o problema de forma mais sutil
Agora dá para gerar uma arquitetura complexa em 5 minutos, mas o custo de manutenção continua o mesmo
Como resultado, estruturas mais vistosas são criadas rapidamente, e documentos para promoção ficam prontos num instante
Mas, na prática, ninguém entende aquele código por completo
O verdadeiro critério de simplicidade é: “a próxima pessoa consegue entender sem fazer perguntas?”, e código gerado por IA ainda não passa totalmente nesse teste
Agora isso só vai piorar
Por isso, eu uso a força da cultura de entendimento do código na organização como critério para escolher minha carreira
Não quero passar de novo por uma situação em que ninguém conhece o sistema
Se o objetivo é resolver o problema, seja com uma ferramenta feita por IA ou comprada pronta, no fim ela precisa resolver o problema
Mas, se um produto pronto não servir, as soluções customizadas geradas diretamente vão aumentar
Só que, se ninguém entendê-las, a próxima pessoa vai acabar fazendo tudo de novo
Ainda assim, isso pode ser uma melhora no sentido de aproximar usuários e criadores
Por exemplo, ajuda deixar explícitas em
AGENTS.mddiretrizes como “KISS” e “YAGNI”O problema é que a “próxima pessoa” acaba sendo eu mesmo daqui a 6 meses
A IA também sofre do mesmo problema por causa dos limites da context window
Muitos desenvolvedores só perseguem stacks populares e não consideram a facilidade de operação
A IA também não vai dizer: “isso é overengineering”
Se você quiser Kubernetes e ElasticSearch, ela simplesmente vai montar isso para você
Tendo passado por FAANG e startup, diria que o essencial é o equilíbrio entre complexidade e simplicidade
Em empresas grandes, gambiarra pode prejudicar a produtividade de milhares de pessoas,
e em startups uma infraestrutura excessiva pode afundar a empresa
O engenheiro realmente experiente é aquele que distingue os dois cenários e sabe escolher os trade-offs adequados com base na experiência
Quando trabalhei na Amazon (2005~2008), havia dois prêmios que simbolizavam a cultura da empresa
O prêmio “Just Do It” representava resolução proativa de problemas, e o prêmio “Door Desk” simbolizava economia e simplicidade
Houve um caso em que um funcionário recebeu um prêmio por remover uma TV inútil, e a recompensa foi justamente essa TV
Como metáfora da simplicidade, na prática era meio ambígua
Para defender a simplicidade, é preciso expressá-la na linguagem do negócio
Algo como “80% menos incidentes”, “40% de redução de custo”, “33% de melhora de performance”
A simplicidade em si não é avaliada, mas seus resultados são muito valorizados
Eu converti refatoração em modelo de custo, medi KPIs e reduzi o MTTR em 60%
É preciso mostrar esse tipo de número diretamente para ser reconhecido
Como gerente, eu preferia código simples
Mas isso também era porque o time era composto por pessoas experientes
Em equipes menos experientes, acontece algo como The Parable of The Toaster
Com a idade, a pessoa passa a resistir mais à complexidade
Mas a liderança muitas vezes interpreta isso como “está se opondo porque não entende”
Os projetos que mais duraram eram os simples e fáceis de substituir
Ferramentas de IA tornam essa abordagem mais fácil — dá para experimentar componentes em projetos de amostra independentes e integrar o código validado ao projeto principal
Em ambiente de rede interna não conectamos IA diretamente, mas esse método é muito útil
Por isso eu proponho: “eu consigo fazer algo complexo também, mas vamos começar com a versão simples primeiro”
Na maioria dos casos, essa versão simples acaba virando código de produção que roda por anos
Um desenvolvedor que entrega rápido uma solução simples consegue implementar várias funcionalidades no tempo que sobra
Já quem fica preso a uma solução complexa gasta semanas em uma única funcionalidade
No fim, em métricas de produtividade, a abordagem simples parece mais atraente
Eu também construí minha carreira mais como alguém que entrega resultados de forma consistente do que como alguém das “grandes ideias”
Uma das entrevistas da nossa empresa é um problema de design de sistema para biblioteca pública
Primeiro começa no porte de uma biblioteca de cidade pequena, depois evolui para um cenário de escala nacional
A melhor resposta era: “mesmo no maior tamanho, um servidor intermediário com Postgres basta”
Na prática, 10 ou 10.000 muitas vezes não fazem tanta diferença, e frequentemente é um entrevistador sem experiência apenas lendo o prompt
Depois, infraestrutura excessiva e desenvolvimento voltado para currículo pioraram o problema
No fim, acho que a IA é uma ferramenta que amplifica a capacidade do usuário
Para desenvolvedores experientes, aumenta a produtividade; para pessoas inexperientes, vira uma ferramenta que espalha confusão mais rápido
Pelo contrário, ela tende a adicionar funções wrapper desnecessárias e conversões de tipo
Tenho a sensação de que a IA fica mais do lado de “adicionar mais código”
Ainda assim, o aumento do “vibe coding” superficial preocupa
Os entrevistadores que conheci também pareciam preferir a complexidade.
Nem espero que a simplicidade seja bem avaliada. Na prática, tem gente que até é promovida por consertar a confusão que ela mesma causou ao tornar tudo mais complexo.
A superengenharia para inflar a própria capacidade, em vez de projetar para o serviço, é algo disseminado.
Acho que o ideal é que quem avalia tenha um bom nível de entendimento.
E também é verdade que é preciso ouvir explicações suficientes.
Se houver alguém em cima capaz de avaliar esse tipo de coisa, então estaria tudo bem, mas como isso nem acontece desde o começo, esse tipo de coisa não é avaliado de forma justa, e por isso essas pessoas não conseguem subir...
Isso vira um ciclo vicioso...
Do ponto de vista da empresa, parece que só quando alguém tem sucesso como um engenheiro equilibrado e sobe na hierarquia é que dá para manter bons engenheiros e também os princípios de engenharia.
Na maioria dos casos na prática, não é mais uma questão de saber apenas implementar funcionalidades de forma simples vs. conseguir projetar com escalabilidade e ainda lidar bem com os trade-offs?
Mesmo que o trabalho tenha sido feito de forma complexa, ainda dá para dizer que foi a implementação da funcionalidade X.
A diferença está em como você expressa isso para quem vai avaliar.