You're doing rubber duck debugging all wrong

One good tip I got to rubber duck debug without another human was to write your questions / explanations in an email or a chat.

I found that indeed, writing an email explaining a problem to a colleague was helpful to solve it despite me never sending the email.

This article offers some useful elaborations on the "rubber ducking" or "Spaniel Method." I blogged about this in https://www.skmurphy.com/blog/2015/09/25/asking-questions-fr... and found an earlier description in a paper published in ACM SIGPLAN in December 1998 “Literate Programming and the ‘Spaniel’ Method” by Nick Hatzigeorgiu and Apostolos Syropoulos. Note that this is a year before Pragmatic Programmer came out. They relate the following advice on “The Spaniel Method” a professor offered Apostolos Syropoulos in response to a request for help debugging a seemingly intractable problem in a program that he was working on:

"As is often the case with baffling errors it is really quite simple. We tend to fixate on incorrect assumptions, and overlook the obvious, surprisingly frequently. I have found that one way to break through such barriers is to use the ‘Spaniel’ method: Carefully explain the program to your dog. Since the dog knows nothing of programming, you must justify every statement you make. In the process you will often discover the mistake.” W. W. Waite

I traced a connection to the Quaker Clearness Committee model, which suggests that the best way for a small group of people to help an individual navigate a thorny problem is not to offer advice but to ask questions designed to uncover greater clarity about the situation.

But this article was useful in drawing a connection to what is also called "Brainwriting" (a model for brainstorming that starts with everyone writing their ideas down first and then comparing them pairwise before moving into a group session) or the 1-2-4-all method from liberating structures http://www.liberatingstructures.com/1-1-2-4-all/

Essentially you use an escalating series of techniques that expose your problem/ignorance to wider audiences, wasting less of other people's time because you frame the problem more clearly as you go--and you may solve it before you ask a large audience for help.

This is simply a methodology for getting the debugger to explain what the problem is in a clear and concise way. It's a variation of the 30 second elevator pitch. In other word, if you can't explain the problem then do you know what you're trying to solve?