Learn Docker With My Newest Course

Dive into Docker takes you from "What is Docker?" to confidently applying Docker to your own projects. It's packed with best practices and examples. Start Learning Docker →

Solve Programming Problems with Rubber Duck Debugging

blog/cards/solve-programming-problems-with-rubber-duck-debugging.jpg

How many times have you ran into a problem and then went to post an issue on GitHub, only to solve it yourself before you hit submit?

Quick Jump: Writing Out the Details Often Fixes the Problem | Remember Pet Rocks?

Way back in the day I used to get upset when GitHub project owners asked a million questions in their issue templates. After all, it’s a lot of effort to fill it out.

A typical project owner might ask you for this information:
  1. What version of the library and OS are you using?
  2. Briefly describe the problem.
  3. List out the steps to reproduce the problem.
  4. Describe the results you received.
  5. Describe the results you expected.

Meanwhile in your head, you’ve just battled a problem unsuccessfully for hours so you might not be in the most rational mindset. You’re thinking about cracking a keyboard over your co-worker’s head because he’s chewing loudly, or if you’re working alone you might get distracted on Youtube.

Writing Out the Details Often Fixes the Problem

I can’t count the number of times I wrote out an issue, only to solve my own problem half way through because once you go through the steps, it forces you to think of everything in great detail. I swear it works like magic.

A lot of times the “list out the steps” part does it for me because it’s so easy to make a mistake, especially if what you’re doing requires a lot of precise syntax. In my latest Docker course, one of the commands we type out is very long and I literally laugh out loud while comparing it to repeating nuclear launch codes. It’s very common to make typos (I do it all the time).

Steps 2-5 force you to think scientifically and break things down. Suddenly thoughts like “it doesn’t work” get shaped into something concrete and you can repeat this process for nearly every problem (programming or not).

You can do this without GitHub too!

Remember Pet Rocks?

You probably don’t (and neither do I), but back in the 1970s some dude thought it would be a good idea to sell rocks and since I’m writing about it here, you can probably guess it was a smashing success (pun intended).

blog/pet-rock.jpg

Yep, back then people forked over their money to buy a plain rock in a box. Then again, people spend $25 today for a bag of organic roasted pistachio nuts with sea salt (yes they exist).

Enter Rubber Duck Debugging

If you’re a software developer, you can explain your problems out loud to anyone or anything and it’s just as effective (if not more effective) than writing out steps 2-5 from above. This term is officially called Rubber Duck Debugging and it works with any object, dead or alive.

I have a Rubik’s cube on my desk that I talk to all the time. It knows my deepest secrets and has also been a part of debugging at least 1,000 programming problems over the years.

The next time you’re stuck on anything, explain everything step by step to your object of choice. Walk through every last detail and leave no stone unturned.

Have you ever used this debugging tactic before? Let me know below.

Never Miss a Tip, Trick or Tutorial

Like you, I'm super protective of my inbox, so don't worry about getting spammed. You can expect a few emails per month (at most), and you can 1-click unsubscribe at any time. See what else you'll get too.



Comments