Why Software Engineers use Rubber Duck Debugging
The concept of talking to a rubber duck might seem completely absurd and hilarious, so you might be surprised to find that programmers of all calibers have been using this method for decades. The name is a reference to a book called The Pragmatic Programmer in which there is a story where a programmer debugs his code by forcing himself to explain it to a rubber duck line-by-line. This concept is closely linked to the Feynman Technique, one of the top learning methods on a global scale.
So, why the rubber duck?
No, you don’t have to start carrying a rubber duck around, in fact, it doesn’t matter whether the item is a rubber duck at all. The idea is that the subject you are explaining your code to isn’t yourself. You can use your imagination, talk to your pet, or any desk items for that matter.
On an editor's note: Pets are not often recommended as they can be distracting. But coming from someone who programs with her cat, I say go for it! However, know that the utmost professional recommendation is inanimate objects.
Humans and computers process information in extremely different ways; computers are all about excruciating precision. Human beings are capable of reasoning, understanding information through ambiguity, and even assumption. You can pick up a toothbrush and execute all the steps to brush your teeth without even thinking, whereas a computer would need a precise and detailed step-by-step algorithm to do even the simplest task.
When a programmer gets stuck fixing a bug, often times the problem originates from a lack of precision in which the programmer was not exact enough with the instructors they entrusted their code with. Other times, the problem stems from the programmer having a hard time understanding their own code.
This is where rubber duck debugging comes into play, by forcing yourself to explain your code line-by-line, you are also forced to truly understand what you are saying, your wording, and the order in which you say it.
Why does it work?
Have you ever seen a child question an adult with a barrage of “whys”? Surely you have noticed how the adult seems to become increasingly more frustrated, or perplexed as to how to answer. Why is that? Two major things take place: The adult realizes they must explain a concept to someone who is far less knowledgeable than they are, therefore they are compelled to find effective ways to do so. Furthermore, the aforementioned strain or frustration comes from a combination of neurological shifts that we’re not necessarily used to engaging with on a daily basis — at least not so in-depth.
Neurological Shifts: From thoughts to speech and focus mode
Speaking, or even imagining speech, generates complex patterns of brain activity, and that’s just regular speech. Now, talking with the intention to explain code not only generates these patterns but simultaneously engages the brain’s Focus Mode.
Focus Mode is known as one of the primary modes in which our brain learns and solves problems. It involves a direct approach to solving problems using rational, sequential, and analytical approaches by concentrated your thinking abilities in the brain’s prefrontal cortex. This is essential for subjects such as math, science, and programming.
When you are faced with thinking about complex topics and translating those thoughts into coherent speech aimed at educating, you’re simultaneously learning and problem-solving as you go. Your brain is actively finding the best approach to translate your thoughts, engaging in active recall, and ultimately processing speech. The combination of mental acrobatics can indeed be strainful but its benefits are immense.
So, I’m teaching my duck how to program?
There is nothing more ignorant than an inanimate object, it is completely devoid of any knowledge, and so are computers until programmers load them up with information. They can’t ask questions, they can’t confirm whether or not they are understanding what you are saying, it is entirely up to you to come up with the questions and answers. Rubber Duck Debugging is highly successful because of this.
How do I do it?
Know that alternatively, you can do this via writing, and it can serve as documentation that you can later revisit. There is evidence that supports that writing, especially by hand, helps our memory(typing is fine as well for rubber duck debugging). However, it is traditionally done by speech as thinking aloud is also linked to enhanced memorizing.
- You can start by explaining your code in a general sense: What is it supposed to do? What problems are you facing?
- Then go deeper into your explanation, get into the details. Explore each line of your code. Be mindful of even the smallest details like where you put a bracket, a parenthesis, why you formated arithmetic the way you did(are you following PEMDAS or other principles, and are they being applied properly?). Even the things that feel like “beginner stuff”.
- If you find yourself having a hard time remembering what a certain function, method, or any sort of execution does, don’t be afraid to look it up in a reputable source. This might be the understanding you are lacking.
- Additionally, this is something I personally do: Make a list of strengths and weaknesses. What are things you felt most confident explaining? What things did you struggle with? You can revisit this and study your problem areas.
Resources:
