Rubber duck debugging

The practice of debugging software by talking to a small toy (like a rubber duck)

Let’s go step by step.

1. Software¹ is usually created imperfect. Errors are by themselves not a sign of a programmer being dumb, or inefficient; the most seasoned hackers still make mistakes all the time.²
2. As one’s experience grows, so does the size and complexity of the software one writes.
3. As any program’s size and/or complexity grows, so does the probability of unknown and/or unexpected errors (“bugs”)
4. As any program’s size and/or complexity grows, so does the subtlety and complexity of its bugs.
5. Past a certain complexity, tracking and eliminating bugs (“debugging”) becomes non-trivial and requires more than just correcting typos.
6. Past a certain complexity, the programmer might be stumped beyond the help of error logs; or it may be impossible or infeasible to look for help on StackExchange.

At this point, it’s useful to turn to Rubber Duck Debugging (RDD).

How to do it? It’s so simple some people—newbies, mostly—doubt its usefulness. You just take a small toy lying around and explain to it what you intend to do and what your program is doing, line by line.

Notice that when I say «explain» I mean actually talking, opening your pie-hole and producing sounds. And when I say «what your program is doing» I mean it in the simplest, most basic terms you can. Don’t just hand-wave your functions—explain your simplest sub-routines—and how they connect to the larger goal you intend.

More often than not, you will stop at some point in the middle of this explanation, realizing what is wrong. And that is where RDD stops.

I’m no psychologist, I don’t know anything about how the brain works beyond my experiences actually owning a brain.

What I do know is that RDD helps by shifting gears in how you see your code. It’s easy to get lost because you think you know how it works. But a good programmer is humble and has no fear of admitting their own mistakes.

Moreover, a good programmer knows that the computer does what you tell it to do, not what you want it to do.

What RDD does is help you «break» your regular reading flow; speaking does make you think differently than just talking to yourself in silence, and explaining it makes you focus on the smallest independent parts of your code, as well as stating how they connect to larger and larger goals.

Astute readers might have already caught on: RDD is a useful tool for pretty much all creative endeavors, not just programming. Any time one hits a roadblock, it’s useful to explain the problem to someone—or something—else, if only to help the brain unclog itself. Performing RDD with a live human also often leads to the “student” asking simple questions that the “teacher” might have skipped, assumed or ignored.

Talking through problems is useful. It’s ironic that RDD itself is handled like many other things in programming: I don’t know how, but it works and so I’m using it. Whatever its underlying mechanism is, it’s both a helpful tool for creative people and a subtle but constant reminder that no one is too smart to be above explaining things to a rubber duck.

1. Please note that Rubber Duck Debugging is a practice that may and should be practiced in all creative branches of life. I will only speak of its original usage in the programming world, but it’s by no means a declaration of it being a tool exclusive only to it.

2. Some might even argue that the zen of programming is making mistakes to learn from.