Here’s a situation I’ve encountered regularly for just about as long as I’ve been programming:
I try and try to solve an odd problem that just should not be happening. I don’t understand why the code is doing what it’s doing. I view and review it, step through it in a debugger, revert to a previous version. Despite all that, the root of the problem is still unclear. I’m banging my head against the wall all day.
At the end of the day, Nadya happens by and asks how I’m doing. Alright, I tell her, but I’m really frustrated with this issue. I start to describe my problem to her.
Thirty seconds into describing the problem, the solution comes to me. Nadya hasn’t said a word.
Sometimes just putting a problem into words can make us think about it differently. Describing it to someone requires us to consider the context and assumptions we have about it.
This pattern is known in some software development circles as rubber ducking, because I can just as easily describe my problem to a rubber duck sitting on my desk as to another human. It’s really a hack for my own brain.
