A ilusão do desenvolvedor herói

A lição mais cara da minha carreira eu aprendi antes de escrever a primeira linha de código profissional, em dois empregos que não tinham nada a ver com tecnologia: nenhum sistema deveria depender de uma pessoa só não quebrar. Eu sei porque, nos dois, essa pessoa era eu.

Foram dois empregos de girar pratos: operações grandes, dessas que não podem parar nunca — e, se um prato caísse, caía em cima de gente de verdade. Num deles fiquei quase uma década; no outro, os turnos eram compridos e os fins de semana vinham no pacote. O endereço de cada um não importa. O que importa é que, nos dois, fui virando, sem perceber, o único que sabia a ordem dos pratos.

Levei anos para admitir o que aquilo significava. Não era motivo de orgulho aguentar tanto — era um sistema com um único ponto de falha, e esse ponto era eu.

Na engenharia de software existe a versão desse mesmo problema, com outro sotaque: o desenvolvedor que resolve tudo sozinho, que sabe de cor onde mora cada gambiarra, o único sem o qual — dizem — o projeto para. Os times aplaudem essa pessoa — ela vira indispensável, e indispensável soa como elogio até alguém fazer a pergunta certa: indispensável para quê? O conhecimento fica preso numa cabeça só. A equipe ao redor não precisa crescer, enquanto o herói aguentar. E o projeto inteiro passa a viver refém de uma disposição, uma saúde, uma vontade de continuar que ninguém tem como garantir para sempre.

Também levei anos para admitir a outra metade dessa lição: eu não estava sendo apenas dedicado. Estava me afundando. Trabalho era fuga, e fuga não fecha às seis — por isso o sábado, o domingo, as doze horas viravam fáceis de aceitar. Quanto mais eu carregava, menos sobrava para sentir o que estava por baixo. As empresas nunca leram isso como problema; leram como entrega. Gostavam muito de mim. E eu, por dentro, confundia ser insubstituível com ter valor — a mesma conta errada, só que em outra moeda.

Hoje escrevo software do outro lado dessa conta. Documentação, teste automatizado, uma especificação escrita antes da primeira linha — nada disso existe para provar competência. Existe para que ninguém, nem eu, precise ser insubstituível para o projeto continuar de pé. O herói de verdade não é quem segura tudo sozinho. É quem se torna dispensável sem se tornar descartável — quem deixa o mapa em vez de ser o mapa.

Documentação é tijolo. Teste automatizado é tijolo. Um processo escrito é tijolo — não porque alguém desconfie de mim, mas porque aprendi, antes de aprender engenharia, que ninguém constrói um cais numa tarde, e ninguém deveria ser cais sozinho. Nem em produção. Nem em casa.

Este texto fecha uma série de cinco, e talvez seja hora de somar em voz alta. O diário que ninguém sabia que escrevia. A etiqueta que devolve endereço ao que estava solto. A fila que exige, sem saber, que alguém sofra na ordem certa. A cópia única que carrega, sozinha, tudo que devia estar em duas mãos. E o cais — o único dos cinco que nunca teve documentação sobre si mesmo, porque quem o construiu passou anos achando que amar era isso: nunca fechar.

Um sistema bom não precisa de herói. Precisa de memória que não dependa de ninguém sozinho — nem da minha cabeça, na próxima empresa, nem do meu cais, na próxima maré.