Existe uma lembrança que carrego com muito carinho: sentado num banco da minha escola técnica, papel milimetrado na mesa, caneta na mão — nenhum computador à vista. O professor tinha escrito um trecho de código C no quadro e a tarefa era simples: rastrear a execução. Variável por variável, pilha de chamadas por pilha de chamadas, na mão.

Isso me fisgou instantaneamente — e mudou a forma como penso sobre tudo.

Lá em 2012, o curso técnico de informática me deu algo que levei anos para nomear: a obrigação de entender o que a máquina realmente faz, não só o que eu quero que ela faça. C não perdoa abstrações vazias. Ponteiro errado, segmentation fault. Lógica errada, comportamento indefinido. Aprendi cedo que computadores são literais — e que essa literalidade é, ao mesmo tempo, a maior fonte de frustração e de beleza da área.

Quando comecei a faculdade em 2016, aquela semente já tinha sido plantada. E a faculdade me deu algo que poucos ambientes oferecem: a liberdade de resolver problemas clássicos do jeito que eu quisesse, dentro das restrições impostas.

Foi numa disciplina de sistemas embarcados que as coisas ficaram sérias. A proposta era implementar soluções para problemas clássicos de computação concorrente — Jantar dos Filósofos, Caixeiro Viajante — em hardware com recursos limitados. Sem swap infinito, sem framework mágico. Só o problema, o compilador, e o microcontrolador na minha frente.

Isso me aproximou de um território que muitos desenvolvedores de software tratam como detalhe de infraestrutura: sistemas operacionais, escalonamento de processos, comunicação entre máquinas. Aprendi que entender onde o código roda é tão importante quanto entender o que ele faz. E que redes de computadores não é a camada que aparece quando tudo está funcionando — é a camada que aparece quando algo quebra.

Hoje, quando preciso debugar uma integração distribuída que falha intermitentemente, ou quando estou desenhando uma solução que vai atravessar três serviços e vários bancos de dados, percebo que aquela base faz diferença. Não porque sei tudo, mas porque sei as perguntas certas: o que pode falhar aqui? Onde está o estado? Quem é responsável por essa entrega?

O ponto de virada de qualidade no meu código aconteceu quando comecei a trabalhar em ambientes corporativos de verdade.

Antes, eu escrevia código para resolver o problema. Depois de alguns meses num time, percebi que estava escrevendo código para apresentar a solução — e essa distinção é enorme. Quando você sabe que alguém vai ler o que você escreveu, que um colega vai abrir seu PR e formar uma opinião, algo muda. Você para de nomear variáveis com abreviações. Começa a quebrar funções grandes demais. Escreve o comentário que o próximo desenvolvedor vai precisar, não o que você já sabe.

A primeira vez que um desenvolvedor mais experiente apontou para um PR meu — não pelo que ele entregava, mas por como estava escrito — e disse que era bom, entendi que estava no caminho certo. Não perseguindo aprovação, mas encontrando confirmação de que o cuidado que eu estava colocando no ofício realmente significava alguma coisa.

Por essa época mergulhei no trabalho de Robert C. Martin e Martin Fowler. Refactoring, clean code, princípios SOLID — não como dogma, mas como vocabulário. Uma forma de nomear o que eu já sentia intuitivamente, e um framework para tomar decisões melhores quando a intuição não bastava.

O que esses autores me deram, mais do que técnicas, foi uma atitude: código é um meio de comunicação entre desenvolvedores. A máquina executa qualquer coisa que compile. Quem precisa entender o que você escreveu é o humano que vai manter isso em produção às três da manhã, seis meses depois — e esse humano é, com frequência, você mesmo.

Hoje carrego isso para as revisões de código que faço no meu time. Não como alguém que critica, mas como alguém que acredita que um feedback bem entregue num PR tem mais impacto do que horas de documentação escrita depois. Que uma cultura de cuidado com o código se constrói nas pequenas decisões diárias: o nome da variável, a função que faz uma coisa só, o teste que documenta a intenção.

Não tenho código perfeito — ninguém tem. Mas acredito que a busca por isso é o que separa software que envelhece bem de software que vira dívida técnica.

E eu ainda prefiro entender o que a máquina está realmente fazendo.