The Programmer Soliloquy

I talk to myself all the time.  Well, not exactly to myself, but when you’re addressing such a rowdy bunch, you might as well be:

The Rowdy bunch

From Left to Right: (Front Row): Rubber Ducky, Oblivion Septim coin, Amazon Ninja w/ Ninja star, Goomba, Mario, and Bob omb
(Back Row): Winter Penguin (my Power Animal), Helicopter [Lego] Ben, Bobblehead Yoda

The ‘talking to myself’ thing isn’t pathological (I swear!), rather it’s a valid way to solve problems:

At its core, when you ask someone something you consciously articulate it. You explain it and frame the issue for the person. Most importantly however, you explain it and (re)frame it for yourself. You give direction to your other-than-conscious very clearly. Now you may question why actually articulating something gives any different result to just sitting there unspeakingly struggling with the question.

Two things. First, in giving words to (or writing onto paper) an issue and adding the clarity and clarifications required to make something understandable to someone else has the same impact on your other-than-conscious. You may think that you’re being clear about an issue in your head, but you rarely are. You’re more likely to be half articulating the issue and then immediately looping into the  same consciously derived result you keep on getting which is failing to remove the problem or blocker.

The Pragmatic Programmer talked about it at length and called it Rubber Ducking:

A very simple but particulary useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and no his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.

It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yoruself. By having to verbalize some of these assumptions, you may suddenly gain insight into the problem.

Why “rubber ducking”? While an undergraduate at Imperial college in London, Dave [David Thomas] did a lot of work with a research assistant named Greg Pugh, one of the best developers Dave has known. For several months Greg carried around a small yellow rubber duck, which he’d place on his terminal while coding.

I’m impressed how well it works.  This morning I was hanging out with a developer friend of mine for breakfast, and going over why a method that wouldn’t work under POST, but would work under GET in ASP.NET MVC.  While explaining the problem to him, I realized the solution.  I took it to work, and sure enough, it worked.

I’m not saying you need a winter penguin or a Yoda bobblehead; you just need some[s/thing/one/] to talk to.

Leave a Reply