Be the Rubber Duck

Author: 

There is a common problem solving technique in programming, called “Rubber Duck Debugging”. This technique is used when a programmer is stuck on a problem with their program, and their usual approach to debugging is not yielding results. Once this point has been reached, the programmer will explain out loud to a rubber duck what their problem is. Just the sheer act of verbally explaining your problem helps to categorize your problem and serve to give you a better understanding of what exactly you’re trying to tackle. Also, it does not need to be a rubber duck, you can talk to any object, or even another person! A lot of the power of this technique comes from the fact that saying a problem out loud forces your mind to spend longer amounts of time on every aspect of the problem. Most really tricky debugging problems come from an assumption that the programmer has that turns out to be false. When you talk about your problem out loud, those assumptions are shepherded through your mind at a slow pace, and their flaws are exposed to you.

Now when you’re a part of a group or team, and you’re working creatively on a project together, it’s important to understand that creative ideas are subjective, and rely heavily on the perspective and context that a person first is exposed to the idea. This is especially important in brainstorming sessions. It’s very rare for an idea in a brainstorming session to be thoroughly thought through, which makes it imperative to frame your feedback on an idea in a very specific way. I like to think of this as “being the rubber duck”. If someone proposes their idea, and you think of a flaw to that idea, restrain yourself from saying “No.” If you say no, and back that up with your reasoning and thought process, that may be helpful, but it is still your reasoning and thought process, not theirs. Instead, become the rubber duck and coax out the thought process by having your teammate spend time on each step of their reasoning for the idea, so that all of their assumptions are brought to light.

To give an example of this, imagine that your team is tasked with making a card game. The theme and core mechanic have been arrived upon already by your team. One of your teammates says “I think we should have secret roles”. If you think that secret roles have no place in the game you are creating, be the rubber duck and coax out the process from your teammate. Try things like asking “Why?”, “What is fun about secret roles?” “Have you played a game with secret roles?” “What was the core concept of that game?” “What is the core concept of our game?” “Do those two match up?”. If you follow this process, brainstorming sessions will be much healthier and the team will be much closer to being on the same page in the long run.

An important thing to note about this technique is that you are not trying to prove how right you are by socratically deconstructing a person’s idea. If you are not immediately willing to have the same done to your ideas, then you shouldn’t be dishing out your advice.