Cover image credit: https://www.pexels.com/photo/yellow-duckies-in-line-on-a-concrete-floor-106144/
What is Rubber Duck Debugging?
Rubber Duck Debugging (or Rubber Ducking) is explaining to an inanimate object what your problem is, and in doing so finding a solution. Typically rubber ducks are used, but any inanimate object will do; my current rubber duck is a giraffe called Stumps!
How to Rubber Duck Debug:
- You get suck in your coding and you can't find the solution.
- Take a deep breath to calm yourself.
- Find a duck, giraffe, monkey, or other inanimate object with a face.
- Explain to your "duck" what the problem is.
- As you're talking your "duck" will implant the answer into your brain! Eureka!
How does it work?
Rubber Duck Debugging works because it forces you to break down a complex problem into smaller chunks as you explain it to your duck. For example:
Dev: "Duck, why isn't my email sending?"
Duck: "..."
Dev: "The email is generated automatically when someone completes the contact form on my website, and it should then send to the site admin..."
Duck: "..."
Dev: "OMG DUCK I'M USING THE WRONG VARIABLE!"
Sometimes we developers can't see the forest for the trees. We're in so deep into our code that we can no longer see the problem, regardless of how obvious it may be. Breaking down the problem section by section, line by line, can help us realise where the issue is.
Speaking aloud also helps us hear our thoughts differently. The very act of hearing yourself explain the problem is often all you need to bring forth a solution. How often have you found yourself just asking "why?" in front of your code and BAM - the solution hits you.
Discussion: What's your experience with rubber duck debugging? Do you find it helps you? Also, please show me your ducks!
Well when I was a freelancer I would just speak to my wife about my frustration with the problem, thus trying to explain it in non-technical words, was sometime just enough to shed some light in the right direction.
Now that I work in an office I just bug one of my colleagues... shame on me :(.
Another trick is to read your code backwards, because it breaks the way your brain is used to think about it.
Another way is to write the docs blocks for each class/function or the README, because it forces you to look into the problem from another perspective.
And for last, sometimes you just need to take a break, and suddenly, when you are not thinking on the problem anymore, your brain gets illuminate with a possible solution for it, or when you are back to the problem you are forced into a fresh start, its just like rebooting your Windows machine to get it back on the right track ;).