Existe uma memória que carrego com bastante afeto: sentado num banco da escola técnica, folha quadriculada na mesa, caneta na mão — sem computador à vista. O professor tinha escrito no quadro negro um trecho de código em C e a tarefa era simples: trace a execução. Variável por variável, pilha de chamadas por pilha de chamadas, na mão mesmo.

Aquilo me irritou da melhor forma possível.

O curso técnico de informática me deu algo que eu demorei anos para nomear: a obrigação de entender o que a máquina de fato faz, não apenas 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 computador é literal — e que essa literalidade é, ao mesmo tempo, a maior fonte de frustração e de beleza da área.

Quando entrei na faculdade, essa semente já estava plantada. E a UFF me deu algo que poucos ambientes oferecem: liberdade para resolver problemas clássicos do jeito que eu quisesse, dentro das restrições que me eram impostas.

Foi numa disciplina de sistemas embarcados que o negócio ficou sério. A proposta era implementar soluções para problemas clássicos da computação concorrente — Jantar dos Filósofos, Caixeiro Viajante — em hardware com recursos contados. 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 muita gente no desenvolvimento de software trata como detalhe de infraestrutura: sistema operacional, 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 rede de computadores não é a camada que aparece quando tudo está funcionando — é a camada que aparece quando algo quebra.

Hoje, quando preciso depurar uma integração distribuída que falha de forma intermitente, ou quando projeto uma solução que vai atravessar três serviços e dois data centers, noto que essa base faz diferença. Não porque eu saiba tudo, mas porque sei as perguntas certas: o que pode falhar aqui? Onde está o estado? Quem é responsável por essa entrega?

A virada de qualidade no meu código aconteceu quando comecei a trabalhar em equipe 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 o seu PR e formar uma opinião, algo muda. Você para de nomear variáveis com iniciais. Você começa a quebrar funções que estão grandes demais. Você escreve o comentário que o próximo desenvolvedor vai precisar, não o que você já sabe.

A primeira vez que um PR meu foi elogiado — não pelo que entregou, mas pela forma como estava escrito — eu entendi que tinha encontrado algo que queria perseguir.

Foi por essa época que me aprofundei nas obras de Robert C. Martin e Martin Fowler. Refactoring, arquitetura limpa, os princípios SOLID — não como dogma, mas como vocabulário. Uma forma de nomear o que eu já sentia intuitivamente e uma estrutura para tomar decisões melhores quando a intuição não era suficiente.

O que esses autores me deram, mais do que técnicas, foi uma postura: o 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 com frequência esse humano é você mesmo.

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

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

E ainda prefiro entender o que a máquina de fato está fazendo.