When someone doesn't experience the unbridled joy of pair programming salvation, it is always something wrong with them, their task, or their partner. Essentially, "oh you weren't pairing correctly" -> "you didn't have enough faith".
Is there any possibility pair programming advocates can cede that developers can eschew pair programming and still produce quality code?
If you are pair programming either by choice or circumstance, it's useful to know some tricks to make it work better. But if you've tried it and don't think it's the right thing, then you should do something else.
How you organize a team is up to you, but pair programming does remain a highly effective tool for some teams. It certainly beats change control boards.
No matter how long you've been programming solo, you can't expect to sit down with a pair and have it "just work". Sure, it happens sometimes, but if it doesn't, you should practice it a bit before discounting the idea.
There are a few things the navigator can do to help out the driver while the driver is typing, but I hesitate to focus on them. In general, both programmers should be engaged. Learn to talk out ideas with your pair in short segments.
TDD helps. Test driving code naturally gives your pair many opportunities to inject their ideas without ruining your train of thought (ie: stop and discuss things at least after every test, preferably much more, but that comes with practice).
It took working with talented pair-programmers at ThoughtWorks to really make it click.
Revealing sentence.
You "had a large measure of doubt about its effectiveness" but since you were a "zealous advocate" (of something you were doubtful about!) you mostly "kept the faith".
Sounds pretty hypocritical and manipulative. How are we to believe your "zealous" declarations now?
No wonder agilists are often dismissed as "One True Way" religious fanatics.
When I pair I'm having an active discussion with the person I'm pairing with about what piece of functionality we're implementing. We don't rubber-stamp things for the sake of it.
If my pair has a great idea on how to do something and I don't, I let them run with it, and then maybe I have an idea that builds on top of that, which I may not have figured out on my own. I'm analysing what they're doing, thinking of ways to improve it as they go.
This idea of one person just coding away while the other person sits there is a mystery to me. If one person is 'passive', you're doing it wrong.
Also, in my experience, two developers working as a pair will have better work ethics and discipline than any of the two taken separately.
BTW, you're calling the one not typing the 'passive' one? That's the wrong attitude.
Really? In this context, I find that I'm the one who often says, "will someone understand what this is doing when they see it the first time?" When it's just me, I may not stop to consider that POV.
The more effective the communication the better the software. If two teams don't work well together, that is reflected in the software.
In a healthy environment, I prefer pairing, for most of the same reasons that are described in the NYT article. But it's not for everyone any more than red crewneck shirts are for everyone.
It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs.
One more thing. The author claims that pair programming helps avoid duct-taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"