Why Do Rubber Ducks Work?

Programming is often perceived by outsiders as a mysterious errand that is mechanical, highly rational, and a bit boring. Managers without an engineering background tend to think of their programmer employees somewhat as machines (without disdain): you’ll never understand how they work, but if you get the good ones and set them up well, they’ll deliver what you need. After working with code and machines day after day, we, the programmers, also build up a belief that our excellence is solely determined by how much we know and how well we know about what we know. However, we shouldn’t forget that programming is a human activity, like all other professions. Psychology plays a significant role in almost all human activities, especially complex ones. And writing code, oh yes, is surely a complicated task.

This story aims to summarize a set of psychological factors that affect a programmer’s performance and techniques that you can use to avoid the traps. It’s based on the reflection of my own experiences and observations of people I worked closely with.

1. The Faithful Rubber Duck

You’ve probably heard of the famous rubber duck debugging technique. Although sounding hilarious, it actually works really well. Your helper may not always be a rubber duck. It could be a mug, a cat (dogs usually don’t work too well), or a very patient coworker. There are several reasons why it works.

First, our brains are so good at taking shortcuts when thinking about familiar things. It’s an excellent evolution strategy since thorough thinking consumes precious energy that we could have used to deal with new situations. Consequently, when debugging, no matter how often you read your code, your brain is constantly skimming, which is never helpful for identifying the subtle logic error that’s causing the problem. When explaining to the rubber duck, you force your brain to slow down and reenter the thorough-thinking mode.

Second, many programmers have ego problems. Your ego still blinds you even when you’re just reading your code without another person challenging you. It keeps fighting against you by telling you everything is good. By speaking your logic out to the rubber duck, you externalize your thoughts as facts, and it’s much easier for us to objectively discriminate facts than challenge the great ideas in our heads.

Third, you form a temporary teacher-student relationship with the duck during the session. Oppenheimer said: “There is no better way to learn than to teach”. Teaching requires a much more comprehensive understanding of the topic. You’d better be very sure about what you say, or you’ll look bad when the duck challenges you.

2. The Shower Effect

Have you ever found a solution to a tricky problem during a shower? Or jogging, swimming, or even sleeping? That happened to me several times.
We think better when our body is feeling relaxed. It’s understandable because an uncomfortable environment forces the brain to resolve immediate issues that (it feels) may endanger your safety. A shower is certainly a form of relaxation compared to an office cubicle. Mild physical activities work similarly. The physical workout helps reduce mental anxiety and lets your brain relax. Of course, the dopamine generated during the course makes it even more creative.

Another reason is that showering (or activities alike) creates a forced break and interrupts your conscious mind from thinking about the problem. However, your subconscious keeps working and sometimes creates strange inspirations you’ll never get by intention. Unsurprisingly, some of the best ideas seem to come out during sleep — when the subconscious dominates your brain.

So, how about convincing your boss to allocate a few shower rooms in the workplace and label them “Shrine of Inspiration”?

3. The Power of Getting Stuck

We get into a sad and demotivated mental state when we are stuck in a situation. Even worse, we tend to enter a “hurry” mode and use hacky solutions to unblock ourselves as fast as possible. We desperately want to make progress. Our “gumption” to create great software quickly dissipates.

Deep down there, it’s fear. The fear that we took all the hardship to reach a dead end, that we need to overturn the entire design and start over, that we’re losing big. “Loss aversion” is firmly encoded in our genes.

You must be aware of the situation, stay calm, and fight against the negative mindset. The dead end has always been there; the best time to run into it is now, not the future. First, being stuck is a fact, a new piece of knowledge that you just learned. Knowledge is always good. It helps you have a new perspective on the system you’re working on. Second, it is a trigger to backtracking, maybe many steps back to some fundamental assumptions you made early on. The awareness can be scary but often leads to some vital revelation: a better conceptual model, a sounder overall design, or a cleverer algorithm.

Also, the loss is not as bad as you feel. You’ve done this thing once. Redoing it will be much faster. The hardest part of programming is never writing code. It’s always understanding what you need to build.

4. Boredom and Anxiety

Life swings like a pendulum backward and forward between pain and boredom. ― Arthur Schopenhauer

I’ll replace “pain” with “anxiety” in the context of programming.

Even the most passionate programmers will admit that most part of the work is quite tedious. It’s a job that takes great patience. From time to time, we get bored. And boredom is the biggest drain of creativity. Boredom can be fought in many ways, but the most effective is turning non-creative tasks into rituals: tasks like proofreading your code before checking in, documenting functions, writing test cases, etc. Once they become rituals, you don’t get bored doing it. Instead, you gain a sense of mission when starting and a unique satisfaction upon completion.

Anxiety is the opposite of ego. It’s the mental state you are so sure you’ll fail, quite often without good reasons. Software development has so many ways of generating anxiety. The problem is it prevents you from focusing on the task and can significantly decrease your performance, eventually making failure a self-fulfilling prophecy. The key to taming anxiety is to materialize your fears. If the design is challenging, what specific requirements are hard to meet? If the schedule is too tight, which components are most risky? If you have a crazy performance goal to hit, which are the most critical paths you need to optimize? Concretizing the fears and externalizing them into tasks usually immediately reduces your level of anxiety and gets you back to the optimal problem-solving mode.

The pendulum of boredom and anxiety leads us to the next and more fundamental topic.

5. The Question of “What Do You Want?”

This is more of a philosophical question than a psychological one.
We want to be better programmers. But how good are you now? What is the definition of a good programmer anyway? Can we quantify the goodness of programming? Can we compare two programmers objectively? Can we even compare two pieces of code objectively?

We use the term “quality” a lot when talking about programmers: quality design, quality code, quality delivery. In this fast-moving and highly competitive software industry, we get a lot of external pressures to be a “good programmer” who creates “quality.” It’s ridiculous since we can’t even define quality.

The more we look outwards, the more we get confused. The solution has to be a self-inquiry. What do you want? It’s not deadlines, features, or even happy customers. They’re forced on you by the environment. Programming is like making music or movies — tension is created and then resolved, and the process gives the artist a great sense of fulfillment. When you start to work on a design, a feature, or a subroutine, you’ve created a tension that you’ll work hard to resolve. Instead of “working” on a thing, you get involved and engaged. You make it personal and put lots of care into it.

Finally, with a resolution, you achieve peace of mind. That process is what “quality work” is about and is the value programming has to an individual.

Final Thoughts

Technical people are so good at thinking technically, and sometimes too much. We shouldn’t forget we are human in the first place. We have emotions. We think irrationally most of the time. The subconscious largely drives our behavior. Admitting that and actively coping with it makes us more effective programmers and happier ones.

References:

• https://rubberduckdebugging.com/
• The Psychology of Computer Programming by Gerald M. Weinberg
• Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig

ZenStack is our open-source TypeScript toolkit for building high-quality, scalable apps faster, smarter, and happier. It centralizes the data model, access policies, and validation rules in a single declarative schema on top of Prisma, well-suited for AI-enhanced development. Start integrating ZenStack with your existing stack now!