Rubber Ducky You’re the One!
An overview of Rubber Duck Debugging
I recently started Flatiron School’s Software Engineering Bootcamp. Despite this being the “in-person” curriculum, we are, of course, learning completely remotely during this global pandemic. While I’ve spent the last seven months realizing that I’m actually pretty ok with limited human contact (the first three months of the shutdown were actually pretty great even though they were spent alone in a cabin in the woods, but not the scary kind), I have very quickly learned that staring silently at deliverables on a screen all alone is… not great. In the first week you do a few pair programming labs, and oh man, were those labs good! It was wild how just saying out loud to another human what the deliverables were asking for made things so much clearer and easier to comprehend! While working on one of these labs I was marveling aloud about how much easier this was. And that was when my partner introduced me to the concept of Rubber Duck Debugging.
Where did Rubber Duck Debugging come from?
The name Rubber Duck Debugging comes from a short story in The Pragmatic Programmer: From Journeyman to Master written by Andrew Hunt and David Thomas, way back in 1999. In this tale, a developer would debug their code by explaining the problems to a rubber duck they carried around.¹ As the story goes a developer hard at work gets stuck on a problem in their code. They walk over to their co-worker and start talking through their problem. Mid-talk they get a flash, the solution! Run back to their desk, make the fix, and keep on trucking. The next day, it happens again, they’re stuck, they go to their co-workers, and boom, problem solved as they talk through it! The next day, the same thing, but this time when they go to talk at their co-worker, they’re stopped. “Hey man, I’m really busy with my own work, I can’t have this chat right now.” “But, but I need — ” “Nope, but I’ll tell you what, I got you this. Here’s this rubber duck, tell it your problems, explain your code to it.” And while the suggestion seems a little off, he does it! Off he goes, talking through his code to a rubber duck. And wouldn’t you know it, he solves his problem!
You want me to talk to a duck?
A duck, a stuffed animal, a cool rock you found out on your daily walk that you stuck some googly eyes on, your reflection, yes, talk to them! Times being what they are, with working remotely on the rise, and social distancing and concern for gathering in enclosed spaces not going away anytime soon, I think rubber duck debugging is more relevant now than ever to today’s programmers, expert, and novice alike.
You see, most of the time when he went to talk to his co-worker he was really just monologuing at them. More often than not it wasn’t the wisdom or guidance of his co-worker presenting him with the solution; it was simply the act of speaking the problem. It’s been proven that we can often solve problems simply by giving voice to them, both in coding and in real life (this is part of why talk therapy works²). Working remotely alone, or even in an office surrounded by our peers, we don’t always have another human available to talk to. So we work with what we have! As an elder millennial (dare I say, Xennial?) who moved home to have the freedom to work towards this career change I dug up this unicorn from the box of incredibly valuable Beanie Baby collector's items that all of our parents still have in the closet, and now she’s my coding partner.
Rubber Ducking through the ages, and why it’s good practice
Rubber duck debugging has a lot in common with other problem-solving methods. From the Socratic method to the Eureka effect (Aha! or eureka moment), among others; one thing they all have in common is using spoken language, either through mono- or dialogue to examine and refine our processes. Some see the Socratic method as a means to seek an answer to a problem, or knowledge, while others see it as a means to demonstrate one's ignorance. However you see it, it’s a method of discourse that has been used for millennia to come to a resolution. Many scientific discoveries lay claim to an Aha! moment. Einstein’s development of his special theory of relativity came to him like a flash while talking about his problem with a friend:
I started the conversation with him in the following way: “Recently I have been working on a difficult problem. Today I come here to battle against that problem with you.” We discussed every aspect of this problem. Then suddenly I understood where the key to this problem lay. Next day I came back to him again and said to him, without even saying hello, “Thank you. I’ve completely solved the problem.” ³
Rubber ducking may not help us solve the theory of relativity, but it absolutely can help us discover that the error pointing to an undefined method in your console, is actually pointing you to the fact that you accidentally tried to create your class with def instead of class. It’s just good practice. By stopping and explaining what’s happening to a captive audience you’ll likely have a better eye for detail. When our brains are running a mile a minute trying to push out deliverables it’s so easy to both make mistakes, and miss them when we start testing. We think faster than we talk, so when we slow down to explain to someone/thing who doesn’t know anything about what we’re talking about we tune into precision in language that we wouldn’t otherwise.
So give it a shot. Find something to talk to. You don’t have to build yourself a TedLexa or an Alexa connected Frankenfish out of a Billy the Big Mouthed Bass⁴, but you could if you really wanted to.
¹ https://en.wikipedia.org/wiki/Rubber_duck_debugging
² https://www.nytimes.com/2020/04/03/smarter-living/talking-out-problems.html
³ Einstein A (August 1982). “How I created the theory of relativity” (PDF). Physics Today. 35 (8): 45–47. doi:10.1063/1.2915203
