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?"
"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?