Um guia prático sobre coisa de paper duck
Quem trabalha com desenvolvimento ou manutenção de sistemas já deve ter ouvido falar da técnica conhecida como paper duck. Não é nada muito avançado, mas causa confusão porque as pessoas tentam complicar o que deveria ser simples. O conceito básico é: você pega um pato de papel e usa ele como um objeto para explicar seu código ou problema para outra pessoa — ou até para si mesmo. O pato não responde, o que é exatamente o ponto. Já vi gente gastar meia hora procurando uma biblioteca nova, quando o problema era uma vírgula errada num JSON. Achei isso há uns dois anos, quando tava debugando um serviço em Node que simplesmente travava sem erro nenhum no log. Coloquei um pato de pelúcia na mesa do monitor, comecei a explicar linha por linha pros dois dedos que sobravam, e numa dessas percebi que tinha declarado uma variável duas vezes no mesmo escopo. Resolvido em 3 minutos.
Como fazer coisa de paper duck funcionar de verdade
A primeira coisa é entender que isso não é mágica, é um processo de externalização. Quando você fala em voz alta, seu cérebro é obrigado a organizar o pensamento de forma diferente do que quando lê em silêncio. O pato entra como um ouvinte neutro, sem julgamentos e sem pressa. O procedimento costuma ser esse: Escolha um objeto qualquer — pato ou não, mas o nome veio dos patos mesmo. Pode ser um caneca, uma figura de plástico, um post-it amarelo. O importante é que seja fixo e visualmente presente. Sente na frente do computador, olhe pros dois olhos do objeto, e comece a explicar o problema em voz alta. Não adianta falar baixo. A voz alta muda a forma como você processa a informação. Diga o que está acontecendo, o que você espera que aconteça, e onde está a divergência entre os dois.
Isso reduz o tempo médio de resolução de bugs simples de 40 minutos para algo entre 5 e 12 minutos, dependendo da complexidade. Bugs mais complexos ainda vão levar tempo, mas pelo menos você vai isolar a parte problemática mais rápido. Tem uma pegadinha que muita gente não leva em conta. A técnica funciona melhor quando o código está em português ou no idioma que você domina. Se você estiver explicando algo em inglês e estiver mais confortável em português, a explicação perde força porque seu cérebro gasta energia traduzindo antes de processar. Use o idioma nativo. O código permanece o mesmo, a explicação é que deve ser natural.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que as pessoas ignoram é o nível de detalhe. Você não precisa dizer "aqui tem um loop que itera os dados". Precisa dizer "esse loop chama a API a cada iteração sem batch, então se tiver mil registros, são mil requisições sequenciais". Quanto mais específico você for, mais chances tem de se dar conta do erro sozinho no meio do caminho. Patos não dão dicas, mas dão espaço para você ouvir seus próprios argumentos com clareza. Tem cenário onde isso simplesmente não funciona. Bugs de race condition, problemas de memória em sistemas concorrentes, erros de compilação gerados por ferramentas automatizadas que você nem vê o código original — nessas situações, o paper duck não adianta. Você precisa de logs, de debugger, de profiler. A técnica é para problemas que envolvem lógica, fluxo, decisão. Não serve para investigações de baixo nível ou para problemas que precisam de execução controlada para serem reproduzidos.
Se o bug for persistente e você já tentou explicar pros dois olhos sem progresso, pare. Saia da cadeira. Vá tomar água, andar, qualquer coisa que quebre o ciclo de fixação mental. A maioria das pessoas volta após 15 minutos e resolve o problema em dois. Ficar parado na mesma posição tentando explicar pra um pato que não responde é, no máximo, meio hora de esforço desperdiçado. O formato original recomenda patos amarelos de borracha ou plástico por um motivo histórico, mas o material não importa. O que importa é o ritual. Você senta, fala, ouve a si mesmo, e o cérebro faz o trabalho que ele estava travado demais para fazer sozinha em modo leitura silenciosa.
Cada vez que o bug voltar, o mesmo processo. Sem frustração, sem drama. Só explicar de novo, sempre com mais detalhes até o erro se revelar.
