
You're doing rubber duck debugging all wrong - danielwbean
https://triplebyte.com/blog/my-guide-for-rubber-duck-debugging-a-better-process-with-no-rubber-ducks
======
nestorD
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.

~~~
wildmanx
This. That's one of the reasons I'm glad I work in a team with competent
colleagues. Not just because I would expect them to answer such an
email/message/bug report comment competently, but I feel encouraged to reach
out _and_ feel it necessary to already myself go into detail and explain all
assumptions I have, everything how I see it, hypotheses etc. With "dumb"
colleagues (which includes a rubber duck), I'd never do it on this level.

So, often times either I solve a problem while writing all this down to them
(or for me/others to read later), or after one or two cycles of them pointing
out something that they didn't understand or didn't follow. I'll then have to
go back and clarify and maybe refresh/refine my own knowledge and it turns out
that that's where the problem was.

------
skmurphy
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...](https://www.skmurphy.com/blog/2015/09/25/asking-questions-from-a-
caring-perspective/) 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/](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.

------
sys_64738
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?

