Pair Programming: Issue 2 : Stop looking at me!
[The second installment of my response to a colleague's queries about Pair Programming]
Issue 2: Many coders are nervous when someone is watching them code over their shoulder. People get embarrassed when they code something that the compiler will catch as a syntax error. People can't concentrate to their fullest.
Nervous, embarrassed, can't concentrate - these are all outcomes of the most basic of things: fear. And the fear in pair programming is exposure to another person's judgment about your performance. "What are they going to think of me?" , "Will they discover I don't know what I'm doing?" , "If I get something simple wrong they'll think I'm an idiot", blah, blah. But this is based on a model of pairing which is false, and usually held by those who have not really experienced true Pairing.
This fear comes from a model where you are programming and your partner is watching and critiquing you. In this interaction the only sounds are the tapping of the keyboard and the occasional, "that's not right", from the critic. In good pairing there are the additional sounds of commentary from the coder and uh-huh-ing from the partner. Think of it like the internal dialogue that often goes on inside your own head when you're doing something, except you're externalising it and the "other voice" really is someone else.
I go back to this "my-our" difference in the Agile attitude: its not my development of X but our development of X. Its not about you, its about us creating a system.
In good pairing the concentration is on the screen on not on the performance of the individual who happens to be in control of the keyboard. In fact because of the nature of the externalization of the dialogue there is often a merging of the way a pair approaches developing code. There is a discussion about the system not about how an individual is doing things.
In my experience the externalization of your inner dialogue coupled with concentration on the instantaneous state of the system as the subject of discussion produces a much higher level and intensity of concentration. Especially if you are practicing Test Driven and Refactoring. In fact, this is one of the reasons the 40-hour week practice exists as the intellectual burn on a pairing situation is so much higher.