Explain it to someone

Last friday, we had a retro, marking the end of another sprint at work.

One of the points I contributed to the board under the “keep doing” column was to explain what you’re working on to someone.

It’s something that I’ve observed especially in the fortnight that has just passed. A colleague would pull me aside to get some help with a nasty bug, an algorithm or just to get a pair of fresh eyes on a chunk of code.

Colleague would start drawing out the context for the specimen in question, then proceed to explain the problem and the almost-working solutions attempted so far. More often than not, colleague would have an epiphany – “Hey, I could have just achieved it by swapping that doodad with a widget and putting it through an infinite loop!”.

I get my 7 seconds of adulation and gratitude as the bringer-of-all-answers. “You’re welcome, glad I could help”, I respond, too embarrassed to admit I lost him 2 minutes into context.

Love my job.

Somehow, the brain seems to piece things together differently when one tries to explain and vocalize the problem. Solutions simply emerge out of the woodwork, that wouldn’t otherwise come up if one were to merely playing it out mentally, or scribbling on paper.

So the next time you hit a doozie, grab someone and try to explain the problem to him/her. That person doesn’t necessarily need to be across the domain of your problem. In fact, sometimes it’s even beneficial for someone to not be clued in because it forces you to explain harder.

All the person needs to do is pretend to listen, ask open-ended questions like “why didn’t that work?”, nod affirmingly at random intervals, and be okay with accepting unearned gratitude and credit.