If you’re part of the software industry you may have heard of rubber duck debugging. The idea is when you’re trying to debug an issue, you’ll explain it to an inanimate object and the answer will present itself. This sounds cute, especially if you visualize yourself speaking to a rubber duck, or teddy bear, or cat. But trust the software industry to find the dark side of any cute idea.

Many software engineers, particularly when they’re just getting started (but not only!) find it hard to strike the right balance between asking questions and figuring things out on their own.

First, they’re afraid of looking “dumb”. Second, many engineers convey (whether on purpose or inadvertently) that their time is too precious to answer “unimportant” questions. Third, often effective communication is neither engineer’s strong suit, and things may break down in that area.

Now, don’t get me wrong – it’s very important to be able to figure things out on your own. One of the most important skills for software engineers, actually. Figuring stuff out on your own helps you grow and learn. And to be honest, interrupting someone for every tiny question you have will hurt their flow, cause some annoyance, and isn’t the most effective course of action if, for example, you have to wait for them to answer. However, sometimes, something that will take you hours or days to figure out on your own can be solved in under a minute by speaking to a person.

Balance is key.

To ask or not to ask, that is the question

This is where the rubber duck comes in. When used correctly, before we interrupt an actual real live person, we talk to the duck as if it was a real person. You explain the context and background, you carefully phrase the problem. You cover what you have done so far to investigate or try and solve the issue. Since you have some motivation not to look “dumb”, you’ll put quite a bit of effort into this process – verify your assumptions are correct and you’ve covered everything you could think of and try yourself. Often, at this point the solution presents itself, and that’s that.

Sounds perfect, right? Where’s the problem?

Explaining a problem to a rubber duck is not like explaining it to another person. There’s no inhibiting factor of not wanting to appear like you haven’t tried enough or not wanting to interrupt someone for no good reason. So, you may skip some of the prep work of explaining the context and background and trying new approaches, in which case the fake conversation is not effective and doesn’t lead to a solution.

But the main problem is that speaking to a duck is actually dehumanizing. Imagine someone telling you to go talk to a duck before interrupting them. That’s embarrassing and humiliating. This sways the balance way too far in the direction of figuring things out for yourself and not asking. Even if that was the most effective way to resolve the issue. Over–communication is not really a problem in the software industry. People have enough trouble scraping up the courage to ask a question, do we really want to discourage them by pointing them at a duck?

Zero ducks

Let’s get rid of the duck and focus on the part that actually matters: Preparing for a conversation.

Write a message or, if necessary, a full fledged document. Include all the relevant context and what you’ve tried so far. Explore those side tracks to double check what you’re saying is accurate and try things that occur to you as you’re writing. By the time you’re done – you either have the answer or are fully prepared to have a useful conversation with someone. You’re being respectful of them and their time by preparing everything you think they need to know ahead of time, and by making sure you really need their help.

Even if this is your best friend at work and you feel that you could contact them with any question you have no problem at all. Even if this is the most attentive senior engineer who absolutely loves mentoring and answering questions. Help them help you, come prepared.

Thank you Shir Granot Peled for making the point that rubber duck debugging wasn’t just “cute” and could be abused in the real world. I hope I’ve convinced some of you to be careful when using or referring to this tool.