Mark Wilden has a lovely post on pairing. From my experience, which isn’t a hell of a lot in this case, I totally agree. Especially this bit (I’m cherry picking parts of this, so please, read the whole thing, it’s absolutely worth the 5 mins):
Pair programming doesn’t encourage quiet reflection and exploration. You can’t just sit back and read some code. You can’t just sit and think. I mean, you can, but then your pair is just sitting there. If you both agree that such contemplation is necessary, that’s fine, but what if your pair is perfectly happy with an existing way? You don’t want to waste their time. You don’t want to argue (unless the other person wants to as well). You give in more often than if you were working alone.
I do this a lot. I dont sit and write code 8 hours a day. I never have, and I doubt I ever will. I tend to think before I code, which may also be why the rigid “write a test, write the code, refactor, repeat” mantra never sits well with me. Sure, I do tests, but I think about what I’m going to write – rather than just rushing in and writing “something” and refactoring it later.
That, to me, is the greatest drawback to pair programming (at least when I’m doing it). You just want to get the story done. Innovation can be stifled. Programming according to generally recognized principles is cast aside, as long as one of the pairs (especially the dominant one) “doesn’t see the need” for it.
…
So that’s why I don’t like pair programming. My weaknesses are exaggerated and my strengths are vetoed. For me, pairing doesn’t work. For plenty of others, it very clearly does work. But not me.
… and I rather agree with that. Maybe it will work for me one day – maybe not. Is it worth a massive drop in productivity – of both parties – to find out?
[really sorry to Mark for giving him the wrong name!]
