I guess it’s been a couple of years now since Dave (pragprog.com/pragdave) and I had a
discussion about attempting to extend some of the benefits of paired
programming (www.pairprogramming.com) to
individual programming sessions. Unfortunately, this 5 minute-ish
conversation resulted in little more than a dangling Wiki link (www.pragmaticprogrammer.com/cgi-local/pragprog?MorePragmaticTips)
with a catchy tag line. I’ve revisited it occasionally to see if
anyone had anything interesting to say.

In his latest Code Kata installment (www.pragprog.com/pragdave/Practices/Kata/KataSeven.rdoc,v),
Dave has—probably unintentionally—started filling in the hole.
He suggests a structured, 3-step approach to reviewing your own code, with
the goal of developing new perspectives in the process. It’s this
same role-playing-ish type of process that I’ve had in mind since we
discussed the "solo pairing" idea.

The Zen Buddhists [oh no…there he goes with that Buddhism thing
again] have developed a concept called "Beginner’s Mind".
Shunryu Suzuki-roshi, author of "Zen Mind, Beginner’s Mind"
(www.booksite.com/texis/scripts/oop/click_ord/addcart.html?sid=3471&Buy=0834800799),
writes:

  "In the beginner's mind there are many possibilities, but in the
   expert's there are few."

As per my limited understanding, the goal is to always think as if you were
seeing or doing something for the first time. Beginners aren’t
usually proud or boastful. They are impressionable. Beginners don’t
already know why things are the way they are or what the best course
of action is at any given moment. They’re more likely to actually
stop and look around them.

This strikes a chord with the solo pairing idea. As we program lone,
there’s a lot of seemingly autonomous stuff that can happen without
any intentional thought. We get into a rhythm, not noticing the familiar
scenery around us. Like driving to work every day, we are dulled to the
routine of the environment in which we work. Think about it next time you
sit down by yourself to write a program: How conscious are you of the names
you choose for variables, methods, or classes? For the "easy"
problems, how critical are you of your own norms and rituals? I’m not
suggesting that you aren’t conscientious—in fact it
might be conscientiousness that has led many of us to a rigid (most of us
prefer to say "correct") way of approaching many of life’s
little problems.

But, when you’re sitting with another person—especially if this
person is a beginner—they’re not inside your head with you.
They’re more likely to question your established protocol. "Why
do you put ‘p underscore’ in those variable names?" This
might be a little frustrating at first until you irritatedly answer,
"Because it shows that they’re parameters to the method. Our old
code’s methods were so long and jumbled that you often couldn’t
remember where a variable was declared, so we had to do this. Thank God
we’ve stopped coding like that…hmm, why do I put those
‘p underscore’s there?"

Dave asks:

  "However, doing this six months after you write code is not the best way
   of developing good software today. So the underlying challenge of this
   kata is this: how can we get into the habit of critically reviewing
   the code that we write, as we write it?"

Maybe we could replace the word "critically" here with
"innocently" to achieve a different but still beneficial effect?