A reminder to talk to the rubber duck
Alongside taking a break from it perhaps one of the most effective ways to solve a tricky problem is to describe it to someone else.
This typically isn’t a problem when pair programming although it can still happen if a pair stays together too long and both start making the same possibly incorrect assumptions when trying to solve a problem.
In this case it makes sense to call someone else over who can lend a fresh perspective to the problem.
At this stage all three people can work through the problem together and then the third person can go back to whatever they were doing before or this can be the catalyst for a pair rotation whereby one of the original two will drop from the pair.
When working alone
When working alone I get into the situation where something 'should' be working but isn’t much more frequently. I find it really frustrating when this happens so I probably call a colleague over to look through the problem more frequently than most.
Frequently just describing the problem to them so that they can help is enough to realise where the problem lies.
I’ve been working with Raph recently and last week on a couple of occasions I found myself imagining a conversation with Raph about a problem I was having and I found that just doing that was enough for me to see where I’d gone wrong.
Luciano Passuello refers to this to as talking to the rubber duck and he describes a way that we can apply this technique silently as well:
There are situations when you can’t make noises or simply can’t afford the social awkwardness of it (“excuse me while I talk to my duck…”). Fear not: do your rubber ducking in writing instead — sure, you won’t have the benefits of verbalization, but the technique still works fine. One way to do it that works particularly well is to write an e-mail message explaining your problem. Pretend you’re going to send it to the smartest (and busiest) person in the world. Describe the problem in detail, the solutions you tried so far and why they didn’t work. List your assumptions and make sure you include all relevant information. Be both thorough and objective. When you are done writing the message, you’ll probably have had many ideas to try out. If not, find a specialized forum and just send it as it is: with your perfectly-crafted message, I’m sure the Internet gods will help you.
I actually hadn’t come across this blog post when I accidentally came across this idea while writing an email describing why something I’d been working on wasn’t quite working.
As I described the main part of the problem it became obvious from reading it back to myself that I’d missed out a small but important detail.
I was then able to go back to the code and fix the problem!
About the author
I'm currently working on real-time user-facing analytics with Apache Pinot at StarTree. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also I co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.