A few days ago, I was listening to Gretchen Rubin’s podcast. Gretchen and her sister/co-host Liz Craft talked about a listener’s suggestion to try the rubber duck debugging method. The listener had written in explaining that this was a trick used by software engineers when they needed to debug code. They simply explain the problem to the rubber duck, and in the process of talking through it, line-by-line, they are able to debug the code.

The suggestion was that this is a hack us non-software engineers could borrow. That by talking through a problem, you might just arrive at a solution. And because there isn’t always someone around to listen as you babble about why something you’ve tried five times now STILL isn’t working (…or maybe there IS someone around but you don’t want to bother them), it’s nice to have a little companion at the ready who is always willing to hear you out.

And whatever frustrating situation you’re navigating, naming a problem is often the first step to solving a problem.

While I’m the furthest thing from a software engineer, the rubber duck debugging method made a lot of sense to me! So I set about searching the house for my own little companion…

Tiny Mark Twain seemed like the perfect choice!

What do you think of the rubber duck debugging method? Would you try it? Do you have a little friend on hand to talk your problems through? I’m starting to think it is a WFH must!

P.S. Here’s another post with something I learned thanks to Gretchen Rubin!