Complexidade de código é ruim
O que parece esperteza no código pode ser, na verdade, o início do caos.
Todo dev já passou por isso de olhar pra um código antigo e se perguntar “quem foi o gênio que escreveu isso?” pra, logo depois, perceber que o gênio era você mesmo, só alguns meses antes. A verdade é que a maioria dos problemas de software não nasce de más intenções, mas de boas intenções levadas longe demais. É o desejo de ser esperto, de usar aquela feature poderosa da linguagem, de deixar o código “bonito”, mas escrever código bonito nem sempre é escrever código simples.
O autor do artigo Simple no site corred.dev, Matthias Endler, parte exatamente dessa reflexão que é a vontade de complicar o que poderia ser direto. Ele lembra que “writing code is easy. Reading it isn’t.” ou seja, o problema raramente está em escrever, mas em manter simples. Complexidade é o resultado de mil pequenas decisões que, isoladas, parecem corretas, mas juntas viram um labirinto. Como ele escreve: “the path to complexity is paved with good intentions.”
Complexidade acidental: o que criamos sem perceber
Nem toda complexidade é ruim. Há a complexidade inerente, que vem do próprio problema que estamos resolvendo e há também a acidental, que é a que nós mesmos criamos. Essa última costuma vir da pressa em abstrair demais, otimizar cedo ou tentar prever cenários que talvez nunca existam. No curto prazo, parece eficiência, porém no longo prazo, isso vira dor de cabeça.
A verdadeira sofisticação está na simplicidade e com simplicidade, aqui, não quer dizer que é falta de ambição, é sim disciplina.
Simplicidade é um trabalho ativo
Como diz o autor, “simplicity is typically not the first attempt but the last revision.” O código simples não nasce pronto: ele surge depois de entender o problema, revisar e cortar o excesso. É o resultado de decisões conscientes, não de improviso. E ele complementa, “simplicity is prerequisite for reliability.” Um sistema simples tem menos peças, menos pontos de falha e mais clareza. Por isso o autor diz que “good code is mostly boring” o que quer dizer que o bom código não precisa brilhar, precisa funcionar.
A maldição do conhecimento
Com o tempo, devs ganham experiência e como certa consequência também um afastamento da perspectiva de quem está começando. Essa é a “maldição do conhecimento”, você começa a achar natural o uso de padrões, macros ou abstrações que deixam o código ilegível pra quem chega depois. Para esse caso, o autor propõe um exercício simples: from time to time, look at “code” through a beginner’s eyes. Trazendo pra qualquer linguagem: olhe para o seu código como se fosse a primeira vez. Se você precisasse explicá-lo em uma call de onboarding, faria sentido, qualquer pessoa entenderia sem conhecimento prévio do resultado?
Como resistir à complexidade
A simplicidade não é um acaso; é uma escolha diária. O artigo sugere três atitudes mentais pra cultivá-la, podendo resumir aqui como:
Comece simples: escreva a solução direta antes de buscar a “arquitetura perfeita.”
Refatore na hora certa: só depois de entender o problema e não antes.
Resista à otimização precoce: clareza quase sempre vale mais que micro performance.
No fundo, dominar uma linguagem é dominar o autocontrole.
Escreva para humanos
E pra finalizar o autor traz uma reflexão: código é, antes de tudo, uma forma de comunicação. O computador entende qualquer coisa, mas quem precisa realmente entender é quem vai manter esse código funcionando, sem bugs e que atenda ao negócio.
A clareza é a maior forma de elegância que existe em software. “Be clear, not clever. Write code for humans, not computers. Simplicity is clarity.” Seja claro, não sabichão. Escreva código pra humanos, não pra máquina.
Referências do artigo
ENDLER, Matthias. Be Simple. corrode Rust Consulting, 11 set. 2025. Disponível em: https://corrode.dev/blog/simple/. Acesso em: 5 nov. 2025.