When you run into tough spots, it’s nice to have another person look at the problem. Rather than immediately visiting a coworker, though, I first turn to another expert:
Let me explain. There’s an established programming practice called rubber duck debugging which is, in my experience, guaranteed to increase productivity and speed your learning. The practice is very simple. To quote The Pragmatic Programmer:
A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.
The technique centers around a very simple idea—to explain a concept, idea, or practice to someone, you first need to completely understand the it. By going through the motions required to explain a concept, you are forced to come to a complete understanding of the issue yourself.
Douglas Adams puts it very well in Dirk Gently’s Holistic Detective Agency:
…if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil , the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself.
At a place like Atomic, I can walk up to anyone, start explaining a problem, and come away with a solution, whether or not I managed to rubber duck the solution out myself during the process of explaining it. That, however, is not the point. By interrupting someone unnecessarily with a problem, you’ve pulled them out of whatever they were engrossed in, costing both of you time.
I keep a rubber ducky on my monitor stand (pictured above) to remind myself to talk or at least think through a problem before bothering someone else with it. On occasion, I’ll even pick it up and have a short conversation. It’s shocking how often stepping back and reconsidering an issue will result in a revelation about the inner workings of a complicated system, or at least new threads to pull on.
What tricks have you learned that let you step back and reconsider problems from a new perspective? Give me a shout in the comments.
 The dim-witted pupil in this quote refers to a computer with a BASIC interpreter and 16k of RAM.