A maldição do desenvolvedor: a responsabilidade infinita de quem tem a capacidade de consertar
(notashelf.dev)- Ao repetir pequenas automações, em algum momento chega-se a um limiar cognitivo em que todas as ferramentas e sistemas passam a parecer coisas que precisam ser consertadas
- Quanto mais a capacidade técnica cresce, mais se vai além de simplesmente perceber os problemas e se passa a carregar o peso emocional de senti-los como responsabilidade
- O desejo de consertar pode ir além de um simples ganho de produtividade e se tornar um meio de regular as emoções; às vezes, isso acaba fazendo a pessoa ficar presa no próprio sistema que criou
- Os sistemas inevitavelmente se degradam com o tempo, e não existe a fantasia de uma solução perfeita
- No fim, a habilidade realmente necessária não é a de consertar tudo, mas sim a tranquilidade emocional de suportar não consertar alguma coisa
O começo está na automação simples
- Tudo começa com pequenos ganhos de produtividade, como um script em Python para renomear arquivos ou atalhos para comandos do
git - Depois de corrigir diretamente os incômodos de um sistema, tudo no mundo começa a parecer passível de melhoria
- Em algum momento, isso deixa de ser “eu consigo” e se transforma em uma compulsão moral de “eu preciso”
O peso da capacidade técnica
- Antes da programação, dava para ignorar um software inconveniente; agora, os problemas aparecem com nitidez
- Código malfeito ou configurações hardcoded criadas por outros desenvolvedores soam quase como uma afronta
- A percepção muda, e todo sistema ou software passa a parecer uma lista de TODOs a serem corrigidos
A vida de refatoração sem fim
- A cada vez surge o pensamento de “eu consigo fazer isso melhor”, e a pessoa mergulha na criação das próprias ferramentas
- Diretórios de código desorganizados, inúmeras tentativas e desistências, e reestruturações intermináveis acabam se tornando um trabalho autoimposto e aprisionador
- Como na metáfora de Kafka sobre “construir uma gaiola e esperar o pássaro”, é fácil cair na produção de ferramentas sem propósito claro
Software apodrece
- Até mesmo um script que parecia perfeito um dia se torna inútil por causa de mudanças externas
- alteração no layout de um site, mudança de versão de pacote, erro de dependência etc.
- Quando o problema aparece, o sentimento não é só incômodo, mas também culpa
- No fim, é preciso encarar a realidade de que manutenção contínua é inevitável
A ilusão da automação
- É comum cultivar a falsa esperança de que “se eu configurar uma vez, nunca mais vou precisar mexer nisso”
- Costuma-se enxergar programação como uma vitória na resolução de problemas, mas ela é apenas uma guerra que nunca termina
- Não existe algo como conclusão definitiva; estamos apenas cavando trincheiras que vivem inundando
Quando programar vira ferramenta de regulação emocional
- Criar ferramentas às vezes é uma reação psicológica para tentar controlar o caos da vida
- Quanto mais complexo o sistema, mais a pessoa sente, paradoxalmente, que está organizada
- Para escapar de uma vida complicada, tenta-se criar um novo app ou refatorar algo, buscando autoconsolo
Burnout sem aviso
- O burnout vem menos do excesso de trabalho e mais de um senso de responsabilidade exagerado
- O pensamento “se eu posso consertar, por que não estou consertando?” intensifica a autocrítica e o estresse
- Essa responsabilidade técnica sem fim se transforma em um peso autodestrutivo
Aprender a arte de deixar pra lá
- Nem todo problema precisa ser resolvido
- Às vezes, saber que você não precisa consertar algo é uma forma ainda maior de controle
- Reconhecer defeitos e simplesmente continuar usando assim mesmo também pode ser uma escolha consciente
A verdadeira habilidade é a clareza emocional
- Mais importante do que a habilidade de consertar é a capacidade emocional de não precisar consertar
- Saber quando parar e distinguir quais projetos são apenas uma forma de autoconsolo
- É preciso se libertar da compulsão de querer consertar tudo e encontrar conforto mesmo na imperfeição
No fim das contas, a habilidade mais difícil na programação é
aprender a deixar algo quebrado como está
21 comentários
Tudo tem um propósito. Se o propósito foi alcançado, não é preciso continuar consertando. Mas, se o propósito não foi alcançado, é preciso consertar.
Acho que o começo é entender claramente qual é o propósito do projeto.
Fica mais fácil quando você percebe que existem empresas que valem centenas de bilhões só por organizar e unificar APIs bagunçadas de bancos e processadoras de pagamento kkk
Cux..
Se, ao ver que um sistema feito em VB 6.0 com COM + OLE + ActiveX ainda continua funcionando perfeitamente, você fica horrorizado e sente o impulso de reescrevê-lo, então você é quem vai sofrer.
No fim das contas, a habilidade mais difícil na programação é
aprender a “deixar em paz o que está quebrado”
Concordo. Sou do tipo que começa a mexer nas coisas, então sempre acabo sofrendo...
Uma automação improvisada por um mero programador obviamente vai acabar quebrando.
Bom conteúdo
Burnout Totdem
: quando você automatiza o trabalho com muito esforço, o colega ao lado é quem vê os benefícios e, no fim das contas, você mesmo acaba sendo colocado para automatizar outras tarefas;
Sou uma das pessoas que automatizou em 2 dias um trabalho que leva 15 minutos e acabou virando “parasita do salário”.
Senso de responsabilidade em excesso é quase uma doença ocupacional de programadores, então isso precisa ser resolvido com processos.
A equipe de Quality Assurance é que deve fazer essa garantia.
O QA consegue conter o excesso de senso de responsabilidade dos desenvolvedores? Não entendi muito bem, então.
Quando vão se acumulando cobranças ao desenvolvedor, discutindo se houve culpa e dizendo "você programou errado",
o desenvolvedor fica pressionado pelo senso de responsabilidade e passa a evitar novas tentativas,
e no fim acaba escrevendo apenas código seguro, sem evolução.
É isso que significa dizer que o QA deve assegurar isso.
Para fazer um desenvolvimento de código que traga avanço, é inevitável assumir certo nível de risco,
e quem deve validar isso e assumir a responsabilidade é o QA.
Dá para ler esse texto dessa forma também? Eu achei que, se fosse para classificar, esse texto era mais uma crítica ao yak shaving.
Como o roxie disse, a história do texto principal realmente é sobre yak shaving,
mas, ao refletir sobre a minha experiência pessoal, acabei falando de algo um pouco diferente do conteúdo principal.
Isso também não poderia ser explicado pelo fenômeno NIH (
not invented here)? Acho que não devemos esquecer que manutenção é, em última análise, custo fixo, e que o custo também inclui o esforço das pessoas.Para conseguir fazer esse tipo de trabalho por muito tempo, acho que às vezes também é preciso praticar deixar de lado o peso da responsabilidade e das emoções antes de cair na armadilha da compensação movida por um senso excessivo de responsabilidade.
Isso também é algo que eu mesmo não consigo controlar muito bem, haha... bom conteúdo.
Acho que este é um ponto muito bom. Responsabilidade, no sentido literal, é sentir-se responsável, então por si só ela não costuma exigir uma compensação. Mas, com o passar do tempo, enquanto o corpo e a mente se desgastam, o senso de responsabilidade não desaparece com facilidade e, para preencher essa lacuna, parece que começamos a esperar uma compensação (mesmo que não devêssemos fazer essa ligação). Sem nem perceber.
Bem, um meio-termo um pouco melhor do que "deixar algo quebrado como está" seria "não mexa até quebrar" :)
Opiniões do Hacker News
Há uma citação que aprendi fazendo teatro. Ela explica o processo da arte como transformar o que é difícil em hábito, o que é habitual em algo fácil, e o que é fácil em algo belo
Apresenta uma opinião pessoal sobre problemas de UI
Desabafa sobre as dificuldades com projetos pessoais
Expressa respeito por engenheiros de software
Faz uma crítica ao perfeccionismo
Compartilha uma percepção pessoal
Menciona que a família e os filhos ajudam a lidar com o perfeccionismo
Escrever software diretamente é mais divertido e oferece soluções mais simples
Afirma que a cultura de obsessão pelo novo é a raiz do problema
Psicólogos classificam as pessoas entre aquelas que buscam maximizar tudo e aquelas que procuram algo bom o suficiente
Parece que uma formulação mais apropriada seria "como deixar de lado o que não é importante" em vez de "como simplesmente deixar algo quebrado do jeito que está"
O que precisa ser consertado, com certeza deve ser consertado
Concordo. Acho que é preciso saber bem se a pessoa está apenas deixando o próprio jardim mais bonito ou se está realmente fazendo um trabalho importante, e saber a hora de largar isso.