When I first learned that part of my Flatiron School experience would be writing/publishing multiple blogs along with presenting them…I hyperventilated. What do I even know at this early juncture? So little. After switching to my eighth or ninth topic, I started pulling out my hair (when I had some). My anxiety was heightening, so I turned to a behavioral technique I’ve learned and used for years- it involves my immediately snapping back into the present moment, and then calmly talking myself through the essential, no-nonsense facts of my current situation.
So I pushed my seat away from my computer, took a deep breath, and asked myself the context of what exactly, factually I’m doing. “I’m absorbing information to write my first blog. I’m going to be presenting to my classmates. It should be pertinent to the material, of course, but it’s just five minutes. Don’t freak yourself out, Jay. It’s good practice. It’s okay.” Then it hit me- I could write about the coding equivalent of this zoom-out ritual; I could write about “Rubber Ducking!”
Now, this is not the brainiest of data science topics, of course. But it may actually be surprisingly important- especially for us newbies- as we 7–15’ers continue to venture through the richly complex jungles of our collective data science education.
The term “Rubber Ducking” or “Rubber Duck Debugging” originated from the influential book “The Pragmatic Programmer: From Journeyman to Master” by Andrew Hunt and David Thomas (1999). As the story goes, an ol’ time programmer used to carry around a rubber duck so that, when his code required debugging, the rubber duck would “force” the programmer to explain the code in detail, line by line. Over the years, this practice has become a part of the practice of developing and debugging coding, as it helps spell out where there are any disconnects between one’s code and one’s intention. In this way, rubber ducking is a “cousin” of other debugging/problem-solving techniques in software engineering (writing pseudocode is closely related, for example; pair programming and peer-reviewing somewhat less so).
In contrast to the structure and content of a typical course textbook, Hunt and Thomas’ work is a hodgepodge collection of short stories, analogies, and ultimately tips to become a better coder. I’d never read it but, after learning everything I have about it, I feel that I now must- it not only spawned this phrase that is now part of coding culture, but so many other well-known concepts, principles, and tidbits (the broken windows theory and the term ‘code katas’ are two well-known examples). In fact, the writers published a second edition earlier this year, 20 years after the original. Here is the original, and then a more practical revised versions of the “official” steps to rubber ducking:
As I’ve alluded to earlier, my own personal experience with rubber ducking in recent months has elicited in me an interesting connection with my understanding and experiences with therapy- I noticed that rubber ducking, in many ways, is analogous to what Cognitive Behavior Therapy (CBT) is in its essence. Okay, in an absolutely butchered nutshell- they break down behaviors, intentions, assumptions, etc. to discern exactly what is going on, not what I think is going on. It has been said that the human brain is a giant associating machine with complex processing; rubber ducking (and CBT) helps guide us through parts our associating machine may have inadvertently mis-interpreted or glossed over. One could say that rubber ducking helps us break down our syntax, semantic syntax, and ultimately semantics in a similar way to how behavioral therapies help break down our thoughts, feelings, and assumptions. There are, after all, meanings that are intended; and there are meanings that are actual fact; in between are what we presume and/or project these meanings to be.
Psychologically speaking, rubber ducking is effective for primarily two reasons:
1) Most of us think much faster than we talk- even more so when we find ourselves in the “zone,” quite suddenly capable of power-typing wondrous code from our beautiful mind as if we’re the late legend John Nash himself. So when we find ourselves in the flip-side of the “zone”- let’s call it “coding purgatory”- verbally talking through the logic in our code forces us to slow our thoughts down to an exact, step-by-excruciating-step pace.
2) Cognitively, we are starting from a place in which we realize that the duck does not know more about the code or problem than we do. This compels us to explain each step in a way that would help the duck- not us- understand the problem; thus, a neurological “shift” takes place that I think is frankly quite cool. It’s not unlike the cognitive benefit one gets by teaching someone who knows less about a problem than they do. One receives a much deeper understanding of the problem by breaking it down and explaining it in concise, exacting non-technical terms.
Your own version of a rubber duck can be just about anything- as long as it is outside of yourself. It also helps if they stay in one spot while you talk (I talk to my cat when rubber ducking).
Rubber ducking is one of the first lines of defense in debugging strategies, alongside quick-tests and googling. It is really about you, the coder, and the code. In the context of an immersive bootcamp such as the Flatiron School, we are surrounded with many other resources- but it’s imperative (and respectful) to work through our coding struggles in a graduated, layered approach. Now, I have way too much admiration and respect for my fellow cohort compatriots to call them a bunch of rubber ducks. And they are most certainly far from mute or inanimate. What I will note, though, is that- for each of us- our classmates play a crucial role as a support layer between the early-phase tools (testing, googling, and Rubber-Ducking) and our amazing-but-super-busy coaches and instructors. So I’d assert that perhaps each of us is surrounded by 21 enhanced, smart-version “rubber ducks” (through “supervised learning,” pun intended).
The general idea is to avoid/minimize extraneously hassling anyone around us (i.e., “I could have found that out on my own using the early-phase tools), but at the same time- and this certainly goes doubly for me- end up in your own endless loop; and don’t suffer in silence. A ballpark figure of 20 mins of earnestly struggling through the code seems to be the standard to start seeking help.
This is a reminder (to myself more than anyone out there) of something I’d picked up somewhere- when your code doesn’t work and it gets frustrating, “embrace the pain,” as the cliche goes; often times, working through these steps will elicit the answer; often times, we are just that one step away from the answer, even if we don’t know it yet.
- On April 1, 2018, Stack Exchange introduced a rubber duck avatar on their websites as a new feature called Quack Overflow. The duck appeared at the bottom right corner of the browser viewport, and attempted to help the visitor by listening to their problem and responding with a solution. However, the duck merely produced a quack sound after apparently thinking and typing. It referenced rubber ducking as a powerful method for solving problems.[4] Some confused visitors seeing the duck for the first time thought that a malware program had been installed in their computer before realizing it was an April Fools’ Day joke.[5]
Sources:
