Em 2021 eu fazia manutenção de notebooks. Chegava de tudo: notebook que não ligava, que desligava sozinho, que esquentava demais, que ligava mas não dava imagem. O cliente quase sempre chegava com um palpite pronto ("acho que é a placa-mãe") e quase sempre o palpite estava errado.

Quando comecei a programar, percebi que eu fazia com o meu código exatamente o que os clientes faziam com o notebook: chutava a causa e saía mexendo. Não funcionava melhor.

Comece pelo sintoma, não pelo palpite

Na bancada, a primeira pergunta nunca era "o que está quebrado?", e sim "o que exatamente está acontecendo?". Liga e apaga? Liga e não dá imagem? A luz de carga acende? Cada resposta corta metade das possibilidades.

No código é igual. "Não funciona" não diz nada. Qual é a mensagem de erro? Em que linha? Com qual entrada? Ler o erro inteiro, com calma, resolve mais problema do que parece.

Teste o mais simples primeiro

Muito notebook "com defeito" era só carregador ruim. Antes de abrir qualquer coisa, eu testava a tomada, o cabo e a bateria. No código, o equivalente é conferir se o arquivo foi salvo, se o nome da variável está certo e se você está rodando a versão que acha que está rodando. É constrangedor quantas vezes o problema está aí.

Mude uma coisa por vez

Se eu trocasse a memória e o SSD ao mesmo tempo e o notebook voltasse a funcionar, eu não saberia qual dos dois era o problema. Aprendi a trocar uma peça, testar, e só então partir para a próxima.

Programando, a tentação é mudar cinco coisas de uma vez "pra ver se vai". Às vezes vai, e você não aprende nada. Às vezes piora, e agora são dois problemas.

Isole a parte suspeita

Quando não dava imagem, eu ligava o notebook num monitor externo. Se aparecesse imagem, o problema estava na tela ou no cabo, não na placa. Um teste simples que separava o problema em dois.

No código faço a mesma coisa: comento um trecho, rodo uma função sozinha, coloco um print no meio do caminho. O objetivo é sempre descobrir de que lado da linha o erro está.

Quase todo defeito tem uma explicação. Só precisa de paciência pra achar.

Anote o que já testou

Com notebook difícil, eu anotava num papel tudo o que já tinha testado. Parece bobo, mas evita testar a mesma coisa três vezes. Hoje faço isso num arquivo de texto quando um bug demora mais de meia hora. Normalmente, no meio da anotação, a resposta aparece.

No fim, a ferramenta mudou, mas o método é o mesmo: observar, testar o simples, mudar uma coisa por vez e não confiar no primeiro palpite, principalmente quando o palpite é meu.