- Durante o processo de rastrear um bug em uma biblioteca open source, surgiu um problema em que o depurador não funcionava
- Mesmo com o código sendo executado, ocorreu um fenômeno em que os breakpoints eram ignorados, e tentou-se encontrar o problema por outros meios
- Foram feitas tentativas indiretas de diagnóstico, como adicionar saídas de log, mas sem obter os insights desejados
- No fim, ao corrigir um erro de configuração do depurador, foi possível observar o comportamento do programa em detalhes e, com isso, resolver o bug
- A partir da experiência de ter ficado tão focado em resolver o problema a ponto de ignorar uma falha na própria ferramenta, o texto enfatiza que desenvolvedores devem primeiro consertar suas ferramentas para resolver problemas com eficiência
Problema ocorrido durante o diagnóstico do bug
- Ao procurar um bug em uma biblioteca open source que estava sendo mantida, ocorreu o problema de o depurador ignorar breakpoints
- Era certo que o código havia executado aquela linha, mas o programa terminava sem parar
- Tão concentrado em resolver o problema, o autor ignorou o problema do depurador e tentou outras abordagens
- Foram feitas alterações no código e tentativas de diagnóstico por meio da adição de logs, mas não se obteve informação útil
Corrigindo o depurador e resolvendo o problema
- Decidiu-se resolver o problema do depurador, e ele foi corrigido com uma alteração de configuração de uma única linha
- Depois da correção, foi possível observar o comportamento do programa em detalhes
- Com base nessas informações, o bug foi resolvido com sucesso
Percepção e lição
- Reconhece-se a situação paradoxal em que a paixão por corrigir o bug acabou levando a ignorar o problema da ferramenta
- Foi vivenciado que, se a ferramenta não funciona corretamente, a eficiência na resolução de problemas cai
- O que desenvolvedores precisam é do hábito de verificar e consertar as ferramentas antes do problema em si
- Com a frase "Fix your tools", o texto termina reforçando para todos os programadores a importância das ferramentas
1 comentários
Opiniões do Hacker News
Tenho 30 anos de carreira, e hoje em dia as ferramentas de desenvolvimento estão quebradas demais
Escrevo código no Linux com o Clio, e os bugs vêm piorando ano após ano
Agora simplesmente deixo passar com um “se não funciona, paciência”. A vida é curta demais para ainda ter que consertar o código dos outros
Quando você tenta corrigir o problema, no fim acaba caindo em "yak shaving"
Ao tentar resolver um problema pequeno, uma sequência interminável de tarefas minuciosas vai se encadeando
O vídeo relacionado pode ser visto aqui
Às vezes, organizar ferramentas e bibliotecas faz a produtividade explodir; em outras, é mais rápido simplesmente seguir no hardcode
A IA ajuda a lapidar as ferramentas, mas ao mesmo tempo aumenta o escopo, e no fim se gasta o mesmo tempo gerenciando ferramentas
No fim, isso é um problema de procrastinação emocional. Você não quer pensar na estrutura inteira e fica repetindo pequenas correções, ou então adia o desenho completo e só fica polindo as ferramentas dos detalhes
Na prática, também é o processo de lidar com atrito e desconforto necessários
Mas é preciso sempre revisar se esse desconforto é realmente necessário
Investir 10 a 15 minutos para automatizar ou encurtar um trabalho repetitivo é, no fim, comprar tempo do futuro
No fim, dívida técnica vai ter que ser paga uma hora, então é preciso criar o hábito de ir quitando aos poucos
Engenharia no fim é uma sequência de afiar o machado
Gosto da abordagem do Kent Beck: “primeiro torne a mudança fácil, depois faça a mudança fácil”
Melhorar o código foi muito mais gratificante do que simplesmente adicionar a funcionalidade
A IA não acha estranho repetir o mesmo código várias vezes, então não há estruturação nem reutilização
Na prática, é mais realista afiá-lo de novo no meio do trabalho, quando ele perde o corte
Dizem “estou ocupado demais agora para afiar o machado!” e continuam trabalhando de forma ineficiente
Achei marcante a frase: “a vontade de corrigir o bug acabava escondendo o fato de que era preciso consertar a ferramenta primeiro”
Kenneth Stanley também trata desse fenômeno em Why Greatness Cannot Be Planned
É um excelente conselho. Eu também tento praticar isso todos os dias
Mas o conselho seguinte — “agora pare de consertar ferramentas e conserte o problema real” — eu não sigo tão bem
Eu também passo por isso com frequência
Corrigir pequenos atritos economiza tempo depois, mas existe a armadilha de ficar mexendo só nas ferramentas sem parar
O mais difícil de verdade é saber a hora de dizer “isso já está bom o bastante” e seguir em frente
Ferramentas têm efeito multiplicador do esforço
Mas é difícil encontrar o equilíbrio entre "yak shaving" e trabalho manual desnecessário
Se você pretende usar a mesma ferramenta no longo prazo, talvez precise pender mais para o lado do "yak shaving" do que imagina, porque até uma melhora de 1% tem grande efeito acumulado
A maior lição é que ferramentas all-in-one em geral são ruins
Usei todo tipo de ferramenta no-code como Make, Airtable e n8n para pipelines de conteúdo, mas acima de certa escala todas quebram
No fim, chamar APIs diretamente com scripts em Python foi muito mais estável
A solução real não foi consertar uma ferramenta complexa, e sim substituí-la por ferramentas simples e transparentes
Ver diretamente o fluxo do código com um debugger é muito útil
Dá para entender de forma muito mais intuitiva do que com análise estática
Se você fica mudando variáveis e breakpoints o tempo todo, fica fácil perder a essência do problema
O debugger deve ser usado apenas para validar hipóteses. Caso contrário, você cai na ilusão de “parece que houve progresso”
Se você gosta desse tipo de texto, dá vontade de brincar dizendo: nunca instale o Emacs