What The Duck is Rubber Duck Debugging?
Imagine passar algumas horas tentando encontrar um erro no código. Você lê uma vez, volta algumas linhas, confere a documentação, abre o log e faz um teste. Nada parece explicar o comportamento estranho. Depois de tanto olhar para o mesmo trecho, acontece uma coisa curiosa: você já não enxerga apenas o código que está na tela. Enxerga também o código que acredita ter escrito.
A variável deveria chegar preenchida. Aquela validação certamente acontece antes. A autenticação já deve ter passado por outro componente. Tudo parece lógico porque, na sua cabeça, a sequência faz sentido.
Até que você pega um pato de borracha, coloca ao lado do computador e começa a explicar o código para ele. Sim, um pato. Você conta que a função recebe o usuário, verifica se ele está autenticado e, caso esteja, chama o próximo processo. No meio da explicação, percebe que pulou uma etapa. Volta ao código e encontra o problema: aquela validação que parecia tão óbvia simplesmente não estava lá.
A estranha história de conversar com um pato
Essa prática ficou conhecida como Rubber Duck Debugging e virou parte da cultura da programação. Uma das referências mais conhecidas aparece em The Pragmatic Programmer, de Andrew Hunt e David Thomas, publicado em 1999.
O princípio é bastante simples: quando você estiver travado em um problema, tente explicá-lo passo a passo para outra pessoa. Essa prática vem do exercicício de externalizar o problema, o chamado self-explanation effect, que continua muito presente na cultura de desenvolvimento até hoje.
O pato aparece em uma anedota relacionada a Greg Pugh, desenvolvedor que mantinha um pequeno pato amarelo de borracha perto de seu terminal. A história foi ganhando vida própria e, com o tempo, o conselho se tornou quase literal: arrume um pato de borracha, coloque-o sobre a mesa e explique seu código linha por linha.
Parece brincadeira de programador, e talvez seja um pouco. Só que a prática toca em algo bastante humano sobre a maneira como pensamos.
Sua cabeça aceita atalhos. Uma explicação, nem tanto
Quando pensamos sozinhos, podemos ser bastante tolerantes com as nossas próprias lacunas. Pensamos que uma informação “já chega validada”, que determinada condição “foi verificada antes” ou que certo trecho “está funcionando”. Como conhecemos o contexto, completamos mentalmente aquilo que não está explícito.
Tente explicar a mesma coisa para alguém que não sabe absolutamente nada sobre o assunto. De repente, você precisa dizer de onde veio o dado, qual deveria ser o resultado, por que acredita que determinada condição é verdadeira e em qual momento ela foi realmente verificada. A conversa fica desconfortavelmente específica, o que costuma ser muito útil.
Pesquisas sobre verbalização, autoexplicação e metacognição ajudam a entender esse efeito. Quando colocamos um raciocínio em palavras, parte daquilo que estava implícito precisa ganhar uma sequência compreensível. Não basta olhar para uma linha e pensar que sabemos o que ela faz. Precisamos explicar por que ela está ali e como se conecta ao restante.
A diferença parece pequena até chegarmos a um trecho que conhecemos muito bem e descobrirmos que não conseguimos terminar a explicação sem recorrer a uma suposição. O bug pode estar justamente nessa pequena distância entre aquilo que está no código e aquilo que nossa cabeça acrescentou a ele.
O pato também sabe escutar
Há outra característica do Rubber Duck Debugging que merece atenção: o pato não interrompe, não conta que já viu um problema parecido, não oferece uma solução antes de entender a pergunta. Essa escuta ativa preserva uma parte importante do processo.
Ninguém precisa ter literalmente um pato na mesa. Dá para fazer algo parecido escrevendo, gravando a própria voz, explicando para uma cadeira vazia ou conversando com outra pessoa. O pato virou um ótimo símbolo porque é difícil encontrar um interlocutor tão disciplinado e, convenhamos, tão pouco interessado em interromper.
E se o pato for uma inteligência artificial?
Hoje existe uma versão bem mais sofisticada dessa conversa. Você pode explicar um problema para uma IA e receber perguntas, hipóteses e possíveis respostas quase imediatamente.
Isso pode ser útil, embora mude um pouco a dinâmica. Se a resposta vier cedo demais, existe a chance de perder justamente aquela parte em que você precisa organizar o que sabe, o que acha que sabe e o que ainda não consegue explicar.
Para quem trabalha com cibersegurança, há ainda uma questão prática. Explicar um problema para uma ferramenta externa exige cuidado com aquilo que está sendo compartilhado. Código proprietário, credenciais, chaves, dados de clientes e detalhes sensíveis de arquitetura não deveriam entrar casualmente nessa conversa.
Nesse aspecto específico, o velho pato amarelo continua com algumas vantagens: não tem conta, não guarda histórico, não transmite telemetria e tampouco se conecta ao Wi-Fi.
O segundo pato dessa história
Existe outra história sobre patos que não nasceu no desenvolvimento de software, mas combina curiosamente com a primeira. Na palestra TEDx “Seja um pato”, apresentada em 2018, Débora Alcantara fala sobre a imagem pouco prestigiosa que costumamos atribuir ao animal.
Leões costumam ganhar metáforas sobre liderança e força. Águias ficam associadas a visão e superação. O pato normalmente não recebe o mesmo tratamento. Existe até a ideia do “profissional pato”, alguém que faz várias coisas sem executar nenhuma delas particularmente bem.
Débora propõe outra leitura. Um pato anda, nada, mergulha e voa. Talvez seja estranho avaliar sua competência escolhendo apenas uma dessas habilidades. A metáfora passa, então, a falar de multipotencialidade, curiosidade e capacidade de adaptação.
Não há uma relação histórica entre “Seja um pato” e o Rubber Duck Debugging. São histórias diferentes que, colocadas lado a lado, criam uma associação interessante. Uma fala sobre explicar um problema até conseguir enxergá-lo melhor. A outra trata da capacidade de mudar de ambiente e combinar habilidades quando a situação pede.
Para quem trabalha com tecnologia, as duas coisas acabam se encontrando com bastante frequência.
Saber muitas coisas não significa saber tudo pela metade
Multipotencialidade às vezes é confundida com superficialidade, embora uma coisa não leve necessariamente à outra. Pense em alguém que trabalha profundamente com segurança e também entende desenvolvimento, arquitetura, comportamento humano e negócio. Esses conhecimentos podem se complementar.
A compreensão de negócio ajuda a explicar por que determinado risco merece atenção. O conhecimento de desenvolvimento permite conversar com engenharia sem transformar segurança em uma lista de proibições. A comunicação ajuda a levar uma questão técnica para uma reunião executiva sem destruir seu significado no caminho.
Problemas reais também têm uma mania inconveniente de atravessar departamentos. O organograma pode dizer que uma questão pertence à segurança, enquanto a solução depende de desenvolvimento, infraestrutura, jurídico, negócio e operação. Saber circular por essas fronteiras ajuda bastante quando o problema se recusa a respeitá-las.
Empresas também enxergam aquilo que esperam enxergar
O desenvolvedor pode olhar para o código e enxergar aquilo que pretendia escrever. Uma empresa consegue fazer algo parecido com sua própria operação.
Frases como “temos uma ferramenta para isso”, “a política está documentada”, “o projeto já foi implementado”, “temos bastante visibilidade” ou “o time conhece o processo” podem estar perfeitamente corretas. O problema aparece quando deixam de ser verificadas e passam a funcionar como premissas permanentes.
Experimente fazer a versão corporativa do Rubber Duck Debugging. Pegue um processo de segurança e peça para alguém explicar o caminho inteiro. De onde vem a informação? Quem recebe? Quem decide? O que acontece quando algo sai do esperado? Como sabemos que o controle está funcionando? O time consegue operá-lo? Qual risco estamos tentando reduzir?
Algumas respostas aparecem sem esforço. Outras começam com uma pausa e um “então…”. Essas geralmente merecem alguns minutos a mais de conversa.
Externalizar o cenário ajuda a separar percepção de evidência. Às vezes, a dificuldade está na tecnologia. Em outras situações, aparece na integração, na capacitação, na governança ou simplesmente em uma premissa que ninguém havia parado para testar.
O que um VAD tem a ver com um pato de borracha?
VAD significa Value-Added Distributor, ou distribuidora de valor agregado, onde um fabricante desenvolve uma tecnologia especializada. Um parceiro conhece seus clientes e leva essa tecnologia ao mercado. Um VAD trabalha entre essas partes, acrescentando conhecimento técnico, capacitação, suporte, implementação, geração de demanda e acompanhamento para que a tecnologia encontre uma aplicação coerente.
A comparação com Rubber Duck Debugging funciona até certo limite. O pato escuta enquanto você explica o problema. Um VAD segue com você, escuta, participa, continua a conversa trazendo repertório, identificando lacunas e apoiando a entender qual camada realmente merece atenção.
A Nova8 atua como VAD e Trusted Advisor em cibersegurança, conectando fabricantes globais, canais e empresas. Essa posição permite observar um mesmo problema por perspectivas diferentes, porque aquilo que chega como oportunidade comercial para um parceiro pode começar como dificuldade operacional para uma empresa e terminar em uma questão bastante específica para o time técnico.
Uma conversa consultiva pode começar de maneira parecida com o Rubber Duck Debugging. Em vez de partir de uma lista de produtos, começa tentando entender o que está acontecendo, o que a organização esperava que acontecesse, o que já foi tentado e quais pessoas precisam participar da decisão.
Depois, a analogia com o pato termina. A Nova8 pode responder, colocar conhecimento técnico na conversa, apoiar a avaliação de caminhos, capacitar parceiros, contribuir com implementação e acompanhar a adoção. O Centro de Excelência em Cybersecurity reforça essa atuação ao aproximar conhecimento técnico, capacitação e suporte da realidade operacional de canais e empresas.
Aproveite para conhecer a consultoria da Nova8
Se sua equipe já olhou para um problema por vários ângulos e a resposta continua pouco clara, uma perspectiva externa pode ajudar a reorganizar as perguntas antes de buscar outra solução.
Aproveite para conhecer a consultoria da Nova8. Um olhar agnóstico pode ajudar a enxergar seus problemas com mais clareza e encontrar caminhos aderentes à realidade da sua operação.
Perguntas frequentes sobre Rubber Duck Debugging
O que é Rubber Duck Debugging?
Rubber Duck Debugging é uma técnica de resolução de problemas em que o desenvolvedor explica seu código ou raciocínio, passo a passo, para um pato de borracha ou outro interlocutor passivo. Ao colocar a lógica em palavras, fica mais fácil perceber suposições, inconsistências e diferenças entre o que o código deveria fazer e o que realmente faz.
Por que o Rubber Duck Debugging funciona?
A técnica força a pessoa a organizar o pensamento e tornar explícitas etapas que poderiam passar despercebidas durante uma leitura mental. Seu funcionamento é coerente com estudos sobre verbalização, autoexplicação e metacognição, embora o Rubber Duck Debugging em si não seja um protocolo psicológico formal.
Preciso realmente usar um pato de borracha?
Não. O pato funciona como um destinatário para a explicação, mas uma cadeira vazia, uma explicação escrita ou até outra pessoa podem cumprir papel semelhante. O importante é reconstruir o problema com precisão, evitando pular etapas que parecem óbvias.
O que Rubber Duck Debugging tem a ver com cibersegurança?
A mesma lógica pode ser aplicada à análise de arquiteturas, integrações, fluxos de identidade, regras de autorização e investigações. Explicar o caminho de um processo ajuda a tornar visíveis dependências, permissões e premissas que merecem ser verificadas. Em cibersegurança, porém, qualquer externalização precisa respeitar confidencialidade e governança.
Qual é a relação entre Rubber Duck Debugging e “Seja um pato”?
A relação é conceitual, não histórica. No Rubber Duck Debugging, o pato ajuda a externalizar o raciocínio. Na palestra “Seja um pato”, de Débora Alcantara, ele aparece como metáfora de multipotencialidade, adaptação e colaboração. As duas ideias se encontram na capacidade de rever premissas e mudar quando necessário.
Fontes principais
- Andrew Hunt e David Thomas – The Pragmatic Programmer
Referência histórica para o princípio de rubber ducking e para a anedota associada a Greg Pugh. - Rubber Duck Debugging – método e passo a passo
Referência dedicada à prática de explicar o código linha por linha para um pato de borracha.
Rubber Duck Debugging - Débora Alcantara – “Seja um pato” | TEDxCentroUniversitárioFAGWomen
Palestra utilizada no artigo para a discussão sobre multipotencialidade, adaptação e combinação de competências.
Seja um pato – TEDx Talks no YouTube - K. Anders Ericsson e Herbert A. Simon – “Verbal Reports as Data”
Artigo publicado na Psychological Review em 1980, usado como referência para a discussão sobre verbalização e pensamento em voz alta.
Verbal Reports as Data – DOI 10.1037/0033-295X.87.3.215 - Michelene T. H. Chi et al. – “Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems”
Estudo publicado na Cognitive Science em 1989 que fundamenta a discussão sobre autoexplicação e identificação de lacunas de compreensão.
Self-Explanations – DOI 10.1207/s15516709cog1302_1
