Engineers Need Rubber Ducks

Saalik Lokhandwala Software Engineer, Applications

Rubber ducks are foundational to a well-functioning development ecosystem. Without them, software developers wouldn’t know how to explain what they were doing.

But “rubber ducks” aren’t always plastic waterfowl. Let’s chat about them, where they show up, and why they’re awesome.


Rubber-ducking is when a software engineer explains code or a concept to someone who nods to themselves, like a rubber duck in a bathtub. It was popularized by a story in The Pragmatic Programmer — a book on the craft of software development.

As engineers, we find ourselves digging deep into stack traces, following long method chains, and trying to pinpoint where our features most elegantly complement the rest of the system. We can trick ourselves into thinking that we understand these systems when we glance at the code. In some of these cases, we don’t.

In those cases, our best friend is a rubber duck. Often, by simply explaining something out loud (or in other ways, as we will soon see), we force ourselves to make connections in our heads, and solutions jump off the screen immediately.

I’ve realized that rubber ducking can exist in many forms and mediums, beyond chatting with friendly plastic waterfowl. Here’s how I’ve improved the quality of my code by communicating with ducks.

Speaking to Ducks

The first thought that comes to engineers’ minds when rubber ducking is breaking down our code by explaining it out loud to an object or another human.

Turning teammates into rubber ducks (and vice versa) is particularly helpful. There are plenty of advantages to rubber ducking with teammates:

When my teammate is the rubber duck:

  • I get to practice breaking a problem down and explaining a piece of the system to another engineer, getting feedback on the clarity of my explanation in the process.
  • I get to experience a-hah moments with my teammates present.
  • I’m able to uncover my blind spots since my team can teach me aspects of understanding I might be missing.

When I’m the rubber duck:

  • I get to learn how my teammate approaches a situation, which might inspire me to look at problems in a novel way.
  • I’m probably getting to understand a brand new part of the codebase that I’ve never seen or understood before.

I’ve paired with senior engineers who have solved problems by simply explaining the problem to me, and I learned a whole new part of the codebase in the process! If that’s not a win-win, I don’t know what is.

Writing to Ducks

Writing is a form of active learning where restating thoughts in our own words strengthens neuronal pathways as our words flow upon a page.

I find myself learning and retaining information best when I write (or type) it down. This is my favorite form of rubber-ducking. I dedicate a note-taking app specifically for this purpose.

When I start working on a feature or fixing a bug that needs a good deal of thought, I open up a page in my digital notebook, and I start writing as if I’m speaking to myself, just dumping my thoughts on the page.

As an example, here’s a snippet from something I was working on recently:

Strangely, the `collapsed` class is added and removed (toggled) only on two clicks. After that, the class doesn’t change at all. When the class is toggled, the caret for the dropdown moves, but nothing expands.

The next step here is to see what’s supposed to show when this is clicked, and try to get it to show from the dev tools.

Even though I might be the only one who can understand my gibberish, rubber ducking through writing is useful for a variety of reasons:

  • Similar to speaking aloud, I’m able to problem solve and have some “aha” moments, by typing on a page.
  • If I had to make a context switch, I can revisit the problem and look at the path my mind took to understanding it, and where I left off.
  • I now have a searchable treasure trove of nuances in the codebase, and rationale for changes made, a far more reliable extension of my memory.

Drawing to Ducks

Other times, it’s best to head to a canvas and create some art for a duck. When problems get particularly gnarly, and especially when there are lots of dependencies and relationships involved, I’ll grab my notebook and draw out my thoughts.

It might end up being a mess of words, boxes, and arrows, but drawing something out might cause that “aha” moment, too. Similar to rubber-ducking through writing, these scribbles might turn out to be useful pieces of documentation, and could even evolve into a polished flowchart!

Rubber ducking is a practice that spans mediums, and it’s a whole lot more than simply debugging a problem. Rubber ducking is an opportunity to knowledge share, get unblocked, and sharpen our thinking, all at the same time.