[TeMPOraL]

Pair programming is a great way to make two people do the work of one, while sweating from stress of the forced close interaction :).

Well, OK. I've heard some teams can pull this off. I've never been in one, though. The problem I had when I tried (beyond the tension from lack of personal space) is, you really have to coordinate a lot of cognitive functions together. I found pair programming easy when it's just one person typing out something trivial, and another checking for typos. But it gets exponentially more difficult if the task is non-trivial, requiring some thinking and exploration up front. You now have both programmers cycling through ideas in their head, with the stress of each idea being subject to immediate evaluation by a co-worker.

The way I see it, successful pair programming requires the kind of brain tuning they did in Pacific Rim - the people involved must be "drift compatible", or else it doesn't work.

[pjmlp]

The only way I ever saw pair programming work was when doing team projects during university, other than that it always feels like yet another branch of agile ideology.

It is the whole stand up routine again, with who types what, how much time the keyboard is given to each one, ....

[sharken]

Pair programming is often mentioned as one way to speed up code delivery as review is included in the activity.

But as you put it, any non-trivial task, e.g. where you're creating multiple new classes and refactoring along the way is hard to do with pair programming.

[username90]

The review you do when pairing isn't a proper review though. The point is to have someone who wasn't there during implementation look at it, while with pairing both people will have similar biases about the code.