When you are stuck on a problem, it often helps to speak to somebody about it. Occasionally they could provide some help or advice that could lead you to some solution. Other times, you do not wind up using another man’s help in any way. You get started describing the problem and then you realize all in your own: oh, this is what is wrong! Or: I have not attempted this yet! This certainly happens a good deal in internet development. When you request the other developer for help with your code, then typically you first must clarify what it is you are building and record the approaches you’ve already attempted to repair it. Stepping back to inspect the big picture may be the secret to finding a remedy. But if only we could exploit this phenomenon without squandering other people’s time by asking them for assistance we do not wind up using. This is the point where a rubber ducky is useful.
A rubber ducky? Just like the toilet toy? However, of course! When you get stuck on something, before you involve someone else, it is helpful to make your situation into a rubber duck initially to get those Aha! Moments from the way. Even if the duck isn’t a help, it is a good practice run for organizing your ideas and covering your bases before you proceed to some more talkative helper. Rubber ducks will sit and pay attention for as long as you will need someone to speak to, without passing judgement or getting impatient. Additionally, they are cheap and add pizazz into a cubicle.
The notion of “rubber duck debugging” might look absurd, but it is a bit of information that’s been passed around for quite a very long time. Wikipediacites narrative in the 1999 book
The Pragmatic Programmeras a potential source for the rubber duck clinic, and if stripped down to its core theory, it looks ideas such as the Socratic Method (but using more ducks). As an alternate to literally speaking into a duck (or some other inanimate object), consider sitting down and writing out each of the items you’d say to somebody in the event that you approached them for support. Imagine that somebody is sitting next to you and you’re describing the problem to them. Often it is good to think about the individual as someone beyond the job — or perhaps outside of your area entirely. What do they ask you? What will confuse them? Which items are not part of the problem and how do you prove that to them?