Rubberducking

Sometimes the best way to solve a problem is to ask for help:

1. Ask someone for help.
2. Get help from that person.

Common enough advice.  But here's the mind-blowing part:

The second step is optional.

A Quick Story

When I was a junior developer, I carpooled with my mentor Bruce to one of our clients once a week.  

It was a 35-minute ride each way.  Oftentimes, I would have gotten stuck on some thorny problem during the day.  On the drive home, I would explain the problem out loud to Bruce to get his thoughts on it.  Regularly, though, the simple act of explaining the problem out loud would lead to me understanding the root of the problem.

I would often arrive at a solution before Bruce even had a chance to respond.

Was Bruce Just That Good?

Bruce was a seasoned developer with tons of experience.

But it turned out that was not a prerequisite for this technique.  The other four days of the week, I drove alone back and forth to the office.  If I had an unsolved problem at the end of those days, I would stew on it in silence on the way home.  If it really vexed me, I would tell me wife about it when I got home.  

My wife is not a technical person.

She cares about my work insofar as she cares about me.  It's safe to say she's not particularly interested in the finer points of Microsoft Access or VBA.  She always asks how my day was.  Most days I'll give a vaguely positive or negative answer, but if I'm really excited or aggravated by something at work, she'll listen patiently while I get it all off my chest.  As I dive deep into the technical details, she matches my emotions, smiling or commiserating as necessary.  We both know that behind her glazed eyes, though, she's thinking about her current sewing, knitting, or cross-stitch project.

Amazingly, though, it matters not that my wife has no idea what I'm talking about.

It doesn't matter that she can't ask insightful questions about possible race conditions or the unusual interactions between Access and linked SQL Server tables.  It doesn't matter because even when I was talking to Bruce, he didn't have to ask follow-up questions at all.  The simple act of me putting the problem into words for another human being was all it took.  In fact, I'm not so sure another human being was required at all.

Explaining the problem to any ... thing ... could work, such as, say, a rubber duck.

Context is the Key... I Think

It's hard to put my finger on what exactly makes this such a powerful technique.

As a rule, I reject monocausal explanations for complex phenomena.  As such, here are several possible reasons why this technique works so well:

• Vocalizing engages different areas of your brain than thinking in silence
• Talking out loud requires speaking in full sentences, which forces you to put together complete thoughts
• It forces you to consciously state your assumptions (which are often taken for granted when thinking in silence)
• To properly explain the problem to someone unfamiliar with it, you must start by providing the surrounding context
• Providing this context is a form of teaching, and teaching requires greater understanding than simply knowing

From my own personal experience, the teaching aspect of this technique, especially as it concerns relaying the context surrounding the problem, is what makes it so powerful.  

As I'm explaining a problem out loud, I'll often hear myself say things like, "First, A happens because of B which then leads to C."  Or, "We have to call X here because of Y even though Z."  At some point, as I'm methodically stepping through the process in plain English, I'll realize that:

1. I've made a faulty assumption (often subconsciously)
2. I have an error in my logic
3. The kind of problem I'm seeing falls into a particular class of errors, which can then open up other promising avenues of troubleshooting (e.g., an incorrect program-wide setting may result from failure to read from a config file or registry location at program startup; ProcMon can help with that)

Conclusion

Rubberducking–whether you do it with another developer, another human being, or an inanimate object–is most effective when you take the time to provide as much context around the problem as possible.  And also when you use the word "because" a lot when providing said context.

So the next time you get stuck on a prickly programming problem, find a fellow nerd, your life partner, or a yellow squeaky bathtub toy*, and follow this simple two one-step process for debugging the issue:

1. Ask someone for help.
2. Get help from that person.

*NOTE: If you are an orange Sesame Street puppet, you may know a certain long-faced, unibrowed curmudgeon who can fill all three of those roles for you.

Additional reading