Pessoas feias e códigos bonitos têm mais em comum do que você imagina
Ser bonito ajuda.

Ser bonito ajuda.
Beleza chama atenção, abre portas e desperta curiosidade antes mesmo da primeira palavra. Mas provavelmente você já conheceu alguém que era muito bonito e, depois de dez minutos de conversa, ficou… menos bonito.
Não aconteceu nada com o rosto. Você apenas descobriu o resto.
A beleza continuava lá. Só já não era suficiente.
E demorei alguns anos trabalhando com tecnologia para perceber que fazemos exatamente a mesma coisa com código.
Programadores gostam de código bonito. Eu gosto. Métodos pequenos, bons nomes, testes passando, responsabilidades bem separadas. Você olha e pensa: “Caramba. Ficou bonito.”
E não tem nada de errado nisso. O problema começa quando confundimos beleza com valor.
Porque um código pode ser lindo, ter 100% de cobertura de testes, zero bugs e uma arquitetura impecável. E ainda assim ninguém precisar dele.
Essa é a parte estranha:
um código pode não ter nenhum bug e, ainda assim, estar 100% errado.
Ele faz exatamente o que deveria fazer. Só não deveria ter sido feito.
Esse talvez seja um dos bugs mais caros que existem. Só que ele não aparece no Sentry. Não quebra o pipeline. Não deixa teste vermelho.
Ele aparece de uma maneira muito pior:
ninguém se importa com aquilo que você construiu.
E isso não significa que qualidade técnica não importa. Importa. Código legível facilita mudanças. Testes dão segurança. Uma boa arquitetura permite evolução.
Mas existe uma diferença: qualidade técnica é um meio. Não é o fim.
Outro programador pode admirar sua abstração. Seu time pode elogiar sua arquitetura. O cliente provavelmente nunca vai ver uma linha do seu código.
Ele percebe outra coisa:
Isso fez ele vender mais? Economizou tempo? Reduziu erros? Resolveu um problema? Melhorou alguma coisa?
No final, código e pessoas talvez tenham mais em comum do que parece.
A beleza pode abrir a porta. É a substância que dá motivos para ficar.
Código bonito importa. Código sem bugs importa. Boa arquitetura importa.
Mas existe uma pergunta anterior a todas essas:
se fizermos isso perfeitamente, o que muda para o negócio?
Porque existe muito código bonito resolvendo problema que ninguém tem. E muito engenheiro dizendo que precisa “gerar valor para o negócio” sem saber exatamente o que isso significa.
Eu também demorei para entender.
Mas isso fica para a próxima.
Nos vemos na próxima quinta, às 10:10.
