The dirty secret of pair programming

The fact that I am reading and responding to this is evidence of my lack of sustained productivity.

When I work by myself (in the office), I'm lucky to get 30 minutes of real work done every hour (some due to interruptions beyond my control, some due to my own lack of focus).

Have a look at the Pomodoro technique. You can work alone and be productive.

1 + 1 = 0

Article title killed me for 5 minutes :-D

Really, it's often no people behind your back to make work process stable and continuity. It's another one thing which give pair programming idea few sense in my mind, after knowledge sharing concept =)

Hi Mendelt, I completely agree with your post and comments. I've translated it in french : Le secret honteux de la programmation en binôme. Regards, Fabrice.

Whilst I concur, it's also important to note that a interruptions force a mental context-switch that may take as long as 10 minutes to get thoughts 'in the groove' again.

If you're interrupted for 10 minutes, you may actually lose 20 minutes.

The suggestion is unsolicited, but if I were you I'd try to tell my peers/colleagues to approach me with their concerns at a particular time of the day; unless they thought it was critical.

What do you say?

Couldn't agree more. But pair working on a same peice of code at a given moment of time somewhat seems conflicting. Plus who would want to "sacrifice" their 10-minutes(tending to 20) break, or their coffee, or the gossips around? I mean, what exactly would motivate us for the Pair programming? One thing could be... the "appreciation" that the pair may get from the management? that may let them continue to Program-Pair'ly. Just thinkin out loud...

usually the biggest complaint against pairing isn't the productivity drain though. it's 'different priorities' for different people. Uniting people on a common priority will probably get people to pair up more often.

Where i work right now every single developer has their own priority. so why would they want to go pair with someone else why their work slips a date?

I think what you say is true but, I think you've missed an important reason why pair programming works. When a programmer is working alone, they are dividing their attention between controlling / responding to the computer's (and the software's) interface and thinking about code. In a pair programming situation, one programmer is the "driver" and the other is able to use all of their brainpower to focus exclusively on the code. Usually, the one who is not driving the computer is the first to notice issues in the code because this person is not preoccupied with controlling the computer and this person has nothing to do when the other person is typing or using the mouse.

I've noticed that it is much easier for me to spot issues when I'm not the one at the computer and I've noticed how even very smart programmers have a hard time seeing the issues I find easily because they are preoccupied with the computer's interface.

I think if you are open to noticing this phenomenon, you will see it all the time.

I think this may be the main reason why pair programming produces higher quality code--the person at the computer is essentially handicapped by their divided attention (like a person trying to drive and talk on the phone at the same time) and having an extra person there makes up for that and allows the pair to be better than they would be individually.