Talking to Ducks
Have you ever called or gone to bother a friend or coworker for some information you can’t think of, only to remember the answer the moment you ask? (I used to work at my college’s IT helpdesk, and once in a while I’d get a call from someone who would promptly say, “Never mind, I figured it out!” as soon as I finished saying hello.)
Identifying an answer or the cause of a bug merely by asking a question or explaining a problem is a common experience for many programmers. It’s particularly common with semantic errors, where the error is a mismatch between what the programmer intended some code to do and what the code actually does. Especially when you just wrote some code, it’s easy to look at the code and assume that what it’s doing is in fact what you intended it to do, which means you can be looking directly at the error and not see it. Thus, one of the most useful techniques when stuck on an annoying problem is to invite someone over to look at your code and explain what you’re trying to do and what’s not working; another person who didn’t write the code won’t be so inclined to assume it does what you think it does and has a much better chance of spotting the error.
That’s great until your coworkers get tired of you interrupting them to look at your code all day. (Interrupting a programmer in the middle of complex work can often cost as much as half an hour of productivity; debugging and other aspects of understanding code rely heavily on juggling many items in short-term memory, and losing track is painful.) Here’s the thing, though: much of the time, you don’t actually need another person at all! While sometimes the other person will have important knowledge you don’t that can help solve the problem, more often than not it’s the process of looking over the code again and explaining the problem that actually yields the solution, and you may be nearly as capable of getting a fresh perspective on your code as someone else, provided you approach it the right way. This has given rise to the practice of explaining problems to an inanimate object or imaginary target (classically, a rubber duck seated in front of the monitor), often known as rubber-duck debugging or rubber-ducking. Only if the duck doesn’t help you solve your problem after a few minutes do you need to proceed to ask another human for help.
Determining how much detail you should use when explaining your problem to the duck is a challenge in moderation. It’s helpful to dumb down your explanation a little bit beyond the level you’ve been thinking at, because if you don’t you may completely pass over the problem – exactly what rubber-ducking is supposed to help you avoid. But you also don’t want to go into exhaustive detail; at some point you’ll be discussing details that don’t matter and drawing your attention away from the information that could lead you to the solution. (Imagine trying to read a book while carefully reading one letter at a time: not only would it be frustrating, you’d learn less.) So some experimentation can be helpful here.
Does RDD work outside of programming? You bet! Talking to yourself, or explaining a situation to someone not present, is an enormously helpful tool just about anywhere. I often try to explain topics I’m learning about to nobody in particular; this helps me reason out things I’m not sure about and also identifies areas that I need to do further research on. Various studies have found that people find objects more quickly and play basketball better when they explain what they’re doing or instruct themselves out loud. I suspect this mechanism is not entirely different from what I remarked on in my post on names, discussing the need to think about things both linguistically and emotionally: by describing the problem (especially by doing so out loud, when possible) you activate a different way of thinking about the same problem that leads to seeing the problem in a new way and ultimately to the solution.
Your partner doesn’t need to be a rubber duck; it could be an action figure or a paperclip or an imaginary friend. But find something and give it a try next time you think you need help: you might save yourself some time and embarrassment.
Also, if you need a good laugh, check out QuackOverflow, a rubber-duck-debugging-related pun on the wildly popular question-and-answer site StackOverflow, originally part of an April Fool’s joke created by same. Click on the duck to get started.
