What the duck?!

Rubber duck debugging is a common problem-solving method in programming. It’s helpful, easy and to be honest, quite cute 🐥. It usually goes likes this: You try to explain to a rubber duck or any other inanimate object for that matter an issue you are struggling with. Soon, and pretty much out of nowhere, the solution comes up into your mind and you’re ready to continue in your work.

And as usual, there’s a science to back it up. #heureka

Since I first started coding in R, which has an impossible learning curve I love to hate, I believe I’ve used rubber duck debugging more often than I actually do the coding itself. It helps me get unstuck (and get stuck all over again with something completely different…), it clears my mind from the clutter that can wait to be solved later, and it always brings me that “a-ha!” moment I enjoy so much. But most importantly it gets my head into the right perspective, a viewpoint if you want, how to solve any problem I run into without overcomplicating it.

I don’t believe there is only one way to use this method, though. I personally managed to develop multiple approaches I switch on a daily basis and when needed. I even “use” people as my rubber ducks. (And you’ll see it’s completely normal.)

So what are the mentioned approaches, then?

Explaining it step by step approach

This one is elementary. You have an idea. To prove it or make it happen you choose to follow a chain of steps. You realize it doesn’t work. It’s not anymore just an idea you are eager to prove, it’s a problem. Now, using your rubber duck debugging method, you go step by step, narrowing the issue down:

“In this step, I did this. Then came this step using these settings. It worked. Then I did this which led to this. Then it keeps on breaking. Why?”

See? Stupidly basic and straightforward. If you want to have even more fun, you can approach this from another perspective and ask yourself: “How did I end up here, even though I did this, I believe, correctly?”

You’ll soon find out that you’ve missed out a step in the code, a part of the more complex procedure, a semicolon, or that the chosen methodology doesn’t really work well with the idea you initially had because you don’t have enough/the right data.

Being an interviewer approach

I was taught this one when I myself was a rubber duck to my former boss. (See, you can use it on people, too!) He was constantly onto something, coming up daily with new ideas and ways how to analyze social media data we were harvesting back then. Always. Most of my days in the office, therefore, consisted of pacing around his table and asking him both stupid (and I dare say as we solved more and more problems) pretty smart questions.

Using this approach I always enclose 3 questions (not in a specific order) while asking others:

Why do you think it does not work the way you want it to?

This one appears a tricky one and hard to answer at first but it forces the interviewed person to explain their methodology and procedure they used in the beginning. Then you want to go on with them explaining what method and why they used and what is the desirable outcome. Then you can go back to analyze why it does not work the way it should and if the method is the right one at all.

What do the results consist of as of now? Are they bad? Really?

This one helps pinpoint possible errors in the code, missing values and missing steps in the pipeline. Also, at this point, you might discover the result is actually good but your initial hypothesis was wrong. And it happens. Often. Trust me.

How did you come up with this idea in the first place?

Funny thing is that using this approach I never got to ask the big question: “Why are you doing this?”. Instead, I want to see how the person solving this problem came up with this procedure, code or the initial idea. Why they want to solve it so badly. By asking this one they will eventually share what is the general knowledge about this topic. You can then ask them about it and prove it true or false together, or even suggest another approach if the current one keeps failing.

Also, I encourage all who teaches classes, to transform their students into rubber ducks eventually. You can learn a LOT by asking questions even though you know nothing about the problem itself. This one specifically teaches you to be a good listener and a problem solver. Don’t be afraid to ask “stupid” questions! The only stupid question there is is the one you didn’t ask out loud.

Ignorance is bliss approach

This one is good for freaking out strangers or your “ignorant” friends over a beer :) Ideally, choose those who don’t know anything about the field you’re working in. At all. By explaining what you’re doing and what you wish to be the outcome to someone who doesn’t know anything about it, you raises the bar of your “say it as simple as you can” skills. Also, you make them feel good because you are asking them to help you. *cheers*

If nothing from the above approaches works, take this one that’s been working throughout the history of mankind: just sleep on it. 

As you can see for yourself, the problems you might have while programming (or elsewhere in your life) can become creative (and fun!) to solve. You just need a little helper.

But don’t worry if you don’t have an actual rubber duck. You can use this cyber one instead. Or just come forward to your friends, mom (FYI: my mom is the best person for these conversations, honestly!) or even a stranger and ask them the most important question here is: Could you be my rubber duck for a while? #quack

Fingers crossed with your programming & have fun figuring out what the duck!

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.