Usando o problema pra resolver o problema

Programadores tem uma tecnica chamada TDD - Test Driven Development. A ideia é começar pelo fim: antes de escrever o código você escreve um teste que define o que o código deveria fazer. Esse teste falha - obviamente, o código ainda não existe. Ai você escreve o minimo de código pra fazer o teste passar. Pronto, próximo teste.

Uso isso todo dia no trabalho. Mas só recentemente percebi que uso a mesma coisa pra quase tudo.

Tinha que cortar uma peça de forro num angulo complicado. Desses que você olha e não sabe nem por onde começar a medir.

Tentei de tudo. Medi, desenhei, medi de novo. Não importava o que eu fazia, o angulo saia errado. O formato que eu queria estava ali na minha frente, era só olhar pro buraco na parede. Mas traduzir aquilo pra uma marca de corte na madeira não tava rolando.

Ai veio a ideia: se o buraco tem o formato que eu quero, usa ele como molde.

Peguei um papelão, encaixei no buraco e fui cortando até encaixar direito. Tendo o molde foi só contornar na madeira. Encaixou perfeito.

Quando decidi alimentar minha casa com energia solar, não sabia nada. O maximo de experiencia que tinha era com aquelas calculadoras antigas que funcionavam sem pilha.

Mas eu tinha um objetivo: tirar minha casa da rede elétrica.

Comprei um painel de 100W, um controlador de carga e um inversor. Fiz uma lampada acender. Funcionou.

E ai percebi que meu objetivo estava aberto demais. “Alimentar a casa com energia solar” não me dizia quantos watts eu precisava, quantas baterias, qual o tamanho do investimento. O experimento me mostrou que eu precisava refinar o objetivo.

Fui medir o consumo dos equipamentos, fazer contas, montar um plano novo. E fazer experimentos novos.

Hoje já sei que meu próximo passo é ter bateria pra 3 dias sem sol. Sei quantos amperes preciso, quanto custa cada bateria. A execução agora é só juntar dinheiro e instalar.

No trabalho é a mesma coisa. Quando preciso corrigir um bug, não saio lendo código tentando entender o que tá errado. Escrevo um teste que reproduz o problema. Quando o teste falha do jeito certo, sei que entendi o problema. Ai é só fazer ele passar.

Às vezes o primeiro teste acaba indo pro lixo. Ele era exploratório, serviu pra me familiarizar com o contexto. É o papelão do código.

É fácil se fixar no sintoma e esquecer do objetivo. Um parafuso espanou - como faço pra consertar? Mas o problema não é o parafuso espanado, é fixar a peça. Joga esse parafuso fora e usa outro.

Fica mais fácil quando você deixa o problema te mostrar o caminho.