Começa de forma inocente.

Você renomeia um lote de arquivos com um script em Python de dez linhas, ou cria um alias para um comando git comum, economizando alguns toques no teclado. Ou talvez construa uma pequena função de shell para formatar JSON a partir da área de transferência.

Você não está tentando ser esperto. Está apenas resolvendo pequenos problemas. Fazendo a máquina realizar aquilo que já deveria ter feito. Mas então algo acontece. Você ultrapassa um limite. Olha para suas ferramentas, seu ambiente, seu sistema operacional—até seu editor—e, de repente, tudo parece estar em jogo.

Você poderia reconstruir isso (se quisesse).

Você poderia melhorar aquilo (se quisesse).

Então, alguém lhe desafia. Pode ser uma brincadeira, talvez de forma jocosa, mas também com uma pitada de esperança. E o clima da sala muda.

Isso se transforma em:

"Você deveria."

E, a partir desse momento, o mundo se descompõe de maneiras novas e específicas que somente você consegue enxergar.

Capacidade Técnica como um Peso Moral

Antes de aprender a programar, o software quebrado era frustrante, mas ignorável. Por anos, eu simplesmente "usei" um computador, como um consumidor. Eu era o alvo que as empresas tentavam enganar para vender seus produtos ou assinar seus serviços, não o técnico que elas preferiam evitar em seus lançamentos de software.

Agora, tudo isso se tornou provocativo. Vejo padrões que preferia não enxergar, descubro falhas que consigo atribuir a uma falta de compreensão de certos conceitos e escuto os ecos na mente da pessoa não técnica que criou o programa que preciso depurar.

Notei falhas como um bom cirurgião nota uma claudicação.

Por que diabos este site envia dez megabytes de JavaScript para uma página estática?

Por que a saída do CLI não é analisável pelo awk?

Por que esta configuração está codificada quando poderia ser declarativa?

Essas questões não são apenas perguntas; são acusações. E, infelizmente, elas não param.

Agora que aprendi a notar, minha percepção sobre software mudou completamente.

Cada peça de software se torna uma lista de tarefas a fazer.

Cada sistema se transforma em uma estrutura para algo melhor.

Cada inconveniência se torna uma denúncia da inação.

Um Dever Imaginar Sísifo Feliz

Como Sísifo de Camus, estamos condenados a empurrar a pedra de nossos próprios sistemas ladeira acima—uma correção, uma refatoração, um script de cada vez. Mas, ao contrário da história de Sísifo, a maldição não é imposta por um deus. Nós construímos a pedra. E continuamos polindo-a ao longo do caminho.

Perdi a conta de quantos projetos comecei com alguma variação de "Sim, eu poderia construir isso, mas melhor."

Um gerador de sites estáticos porque os existentes tinham muitas opiniões.

Uma ferramenta de anotações porque não gostava da forma como outros estruturavam metadados.

Um executor de tarefas CLI porque o Make é críptico e o Taskfile é um inferno de YAML.

Um motor de wiki pessoal em Rust, depois em Go, depois em Nim, e então de volta ao Markdown.

Um painel para homelab porque não gosto de webslop.

A lista continua, e acredite, ela continua. Meu diretório de desenvolvimento já está se aproximando de 30 gigabytes.

Se você me perguntar, estava resolvendo problemas reais, inocentes. Mas, em retrospecto, também estava alimentando algo a mais: uma compulsão por controle. Cada nova ferramenta que construí era um sandbox que eu possuía: Sem bugs estranhos. Sem restrições legadas. Sem decisões com as quais eu não concordasse totalmente. Até que, claro, eu me tornasse a herança.

Kafka escreveu que "uma jaula foi à procura de um pássaro". Isso é o que esses projetos podem se tornar. Sistemas vazios que continuamos construindo, esperando por propósito, clareza ou... salvação? Não sei como mais chamar essa busca.

A Entropia é Invencível

Agora voltemos. De volta ao tempo em que não sabíamos melhor.

O software não permanece resolvido. Cada solução que você escreve começa a apodrecer no momento em que existe. Não agora, não depois, mas eventualmente. Bibliotecas são depreciadas. APIs mudam. Regressões de desempenho surgem. Sua ferramenta outrora perfeita quebra silenciosamente porque libfoo.so agora é libfoo.so.2.

Tive scripts que falharam silenciosamente porque um site alterou seu layout HTML.

Tive formatos de configuração que quebraram devido a atualizações de versão.

Tive containers Docker que morreram porque o Alpine Linux mudou um URL de espelho.

Em cada um desses casos, a resposta emocional imediata não foi apenas inconveniência, mas algo que se assemelha mais à culpa. Eu construí isso, e eu sei melhor. Como não pude prever isso? Hora de consertar.

Se você substituir cada parte do sistema ao longo do tempo, ainda é a mesma ferramenta? Ela ainda serve ao mesmo propósito? E você?

A Ilusão da Finalidade

Acho que mentimos para nós mesmos.

"Se eu apenas acertar essa configuração, nunca mais terei que mexer nela."

"Se eu apenas escrever essa ferramenta, meu fluxo de trabalho será perfeito."

"Se eu automatizar isso, economizarei tempo para sempre."

"Escreva uma vez, execute em qualquer lugar." Que besteira.

É, admito, uma mentira sedutora. Ela enquadra a programação como uma espécie de conquista. Uma série de batalhas que você vence ou desafios que completa. Mas a guerra imaginária nunca termina. Você não constrói um castelo. Você cava trincheiras. E elas inundam toda vez que chove. Os desafios nunca estão completos.

Trabalho Técnico como Regulação Emocional

Sobre o tema de encher este post com referências literárias, permita-me citar o estoico Marco Aurélio.

"Você tem poder sobre sua mente—não sobre eventos externos. Reconheça isso e encontrará força."

Mas a programação nos engana a acreditar que podemos controlar os eventos externos. É aí que começa o sofrimento. Há algo mais profundo acontecendo aqui. Não se trata apenas de software.

Acredito que, às vezes, construir coisas é uma forma de autoconforto. Escrevemos uma nova ferramenta ou script porque estamos desesperadamente em busca de uma pequena vitória. Refatoramos, não porque o código está bagunçado, mas porque sua vida está. Perseguimos o sistema perfeito porque isso nos dá algo para nos agarrar quando todo o resto está girando. Essa é a lição que tirei do uso do NixOS.

Escrevi aplicativos inteiros só para evitar pensar sobre porque estava infeliz. Programar oferece feedback instantâneo. Você roda a coisa, e funciona. Ou não, e você conserta. De qualquer forma, você está fazendo algo.

Esse tipo de agência é viciante. Especialmente quando o resto da vida não oferece isso. Programamos porque podemos, mesmo quando não deveríamos. Porque pelo menos nos dá algo contra o que nos rebelar.

O Burnout que Você Não Vê Chegando

O burnout não vem apenas do excesso de trabalho. Vem da superresponsabilidade.

E a programação, uma vez internalizada profundamente o suficiente, faz tudo parecer ser sua responsabilidade. O site inchado. O script ineficiente. O processo de integração confuso no seu trabalho. Você poderia consertar isso. Então, por que não está fazendo?

A verdade que você conhece muito bem é que não pode consertar tudo. Você sabe disso, sempre soube, independentemente do seu nível de habilidade. Mas tente dizer isso à parte do seu cérebro que vê cada ineficiência como um fracasso moral.

Nietzsche alertou sobre olhar muito tempo para o abismo. Mas ele não avisou o que acontece quando o abismo é um Makefile ou um projeto de 30 mil linhas de código em Typescript.

Aprendendo a Deixar Ir

Então, onde está a saída? Isso é semelhante à representação do inferno de Sartre, onde o inferno são outras pessoas e como elas interagem com seu software? Ou é algum tipo de inferno invertido onde as pessoas criam software com o qual você precisa interagir?

O primeiro passo é reconhecer que nem tudo quebrado é sua responsabilidade consertar.

Nem toda ferramenta precisa ser substituída.

Nem toda experiência ruim é um chamado à ação.

Às vezes, está tudo bem apenas usar a coisa. Às vezes, é suficiente saber por que está quebrada—mesmo que você não a conserte. Às vezes, a coisa mais disciplinada que você pode fazer é afastar-se do problema que sabe como resolver. Há uma força nesse tipo de contenção.

Não é apatia, não. Nem preguiça. Apenas... alguma contenção.

Um Novo Tipo de Habilidade

E se a verdadeira habilidade não for a maestria técnica? Ou melhor, e se for a clareza emocional?

Saber quais problemas valem sua energia.

Saber quais projetos valem a pena manter.

Saber quando você está construindo para ajudar—e quando está construindo para lidar.

Saber quando parar.

Isso é o que estou tentando aprender agora. Depois da empolgação. Depois da obsessão. Depois do burnout. Estou tentando deixar algumas coisas um pouco quebradas. Porque percebi que não quero consertar tudo. Eu só quero me sentir bem em um mundo que muitas vezes não é. Posso consertar algo, mas não tudo.

Você aprende a programar. Aprende a consertar coisas. Mas a coisa mais difícil que você aprenderá é quando deixá-las quebradas.

E talvez essa seja a habilidade mais humana de todas.