One of my favorite debugging techniques is called Rubber Duck debugging. No, you heard that right and it really is a thing. The idea is extremely simple, and is a way to re-organize our thoughts when we get stumped.
First I want to say that Rubber Duck is not just a Debugging Partner. It is a proofreading partner to help you find mistakes. Proofreaders and editors often run into the same problems as developers. And as developers we should use some of their techniques.
Our brain tricks us into thinking what we are reading is correct. It allows us to read what we think we should see on the page instead of actually reading the text word for word.
Melissa Lewis Grimm (link)
This quote is so insightful for developers, because computers are extremely unforgiving and cannot infer context to statements and take each statement literally. Try reading the text on the right and you can see how your mind will invent and interpret ideas that are not accurately written. For developers, our audience has no concept of inaccurate written word. Computers follow every word as it is written.
The Rubber Duck Is Not Just a Bath Accessory
A Rubber Duck is not only a useful toy to distract little ones from bath time, but one that has a hidden super power. The power to solve difficult problems that have plagued programmers for generations.
How many programmers have sat in front of a piece of code for hours on end, staring blankly at the screen, not knowing where a particular problem lies? This happens as we tire of looking at the same piece, over and over, and missing the one nuance that would solve the whole problem.
With more and more people working remotely, there are fewer opportunities to have the level of interaction we used to take for granted. No worries, the Rubber Duck is here to rescue you.
How to Use a Rubber Duck
- Identify the area of code where the problem lies (wolf fencing aka binary search is a good technique as well as problem simplification)
- Within the area of code, without analyzing the code, talk to the rubber duck…out loud… and explain exactly what each line of code is doing. Then explain to the duck what that line is doing, and what information it is interacting with. When you are satisfied that you have an understanding of the code, proceed to the next line. Continue until you have stepped through all the lines of code.
- At this point you may have already found the problem, but if not, go back to step 2 and start challenging any assumptions that you have made while reading the code. For example: was a variable initialized, are multiple threads going through the same code, is there a global variable being used, etc.…
This technique works well when you can isolate the code into its own function/method depending on your language. This allows you to identify all of the incoming variables into the code and allow you to place guard clauses or assert clauses within your code. This has the effect of making you think about all of the assumptions that are baked into the code.
I often use this approach when I have someone come look at a piece of code with me and I do the same thing with them, but without the duck. Having a person with you gives some more advantages. For instance, they will be able to question certain assumptions that you may not have thought of before. Having a fresh set of eyes on a problem is rarely a bad idea.
A Rubber Duck is Not a Hammer
Like most debugging techniques, this is most powerful when used in conjunction with other techniques like binary search, problem simplification, etc. For most developers these have become part of their nature, but for newer developers, it is important to understand some of these basics. Most Developers have made use of this technique, but do not understand why it works so well.
Every developer, manager, solution developer, has a tool chest of their own. A collection of tools and techniques they have mastered, those they feel comfortable with, and those they experiment with. This specific technique has stood the test of time for me and is a permanent member of my problem solving tool chest.
I hope it finds a way into a small area of your tool chest as well.