My main argument against pair programming is that you never feel that you have done anything significant. You can never be proud of a single line of code since it's always made by someone else together with you. You can't take credit for an invention/algorithm, and thusly never get the kick of true craftsmanship.
You are always expendable and can be shoved around like an animal, especially if you are a true team player that always nods and smile are "the best" to pair up with.
In fact, the cowboy programmers still rule the programming session when you pair up with them and they can easily take up most part of the day arguing small uninteristing details until they get it their way making the software theirs - not the team.
Your second and third paragraphs have nothing to do with pair programming. They indicate crappy management (shoving people around like animals) and a crappy team (nitpicky argumentation) respectively.
Your first paragraph is more interesting. How does the fact that someone else also contributed diminish pride in craftsmanship? Presumably it's the program you're proud of, so if the program comes out better, isn't that reason to be prouder? (If the program comes out worse, that's a problem.) Personally, it would drive me crazy to work with people who were constantly worrying about who contributed what. Software development is hard enough as it is. We can't afford to waste valuable cycles on that kind of thing.
My experience has been that the solitary-genius fantasy is the calling card of an immature programmer and is purely something to get over. (Just so it's clear, I'm not drawing this conclusion about you, nor about the OP.)
It may be true that co-programming makes crappy teams worse, but it also makes great teams better. As far as I'm concerned there's nothing better than a small team of smart people hammering on a hard problem together. But there's no question that it forces team dynamics into the open.
I prefer solo programming, but to me it means something different from programming without input from other people. I will ask as many questions as I can in order to get the job done. I will describe my design to key team members so it gets criticized and improved. I will ask people to review my code. But when I actually sit down to write code, I don't want anyone looking over my shoulder (with a few exceptions, such as bug hunting or prototyping).
I think there is plenty of bad programmers and bad managers. I don't think either profession is a lot better than the other. (I am a coder and manager)
Except that it's easy for just about anyone to spot a bad manager. A manager who doesn't actually know how to code couldn't spot a bad programmer if they fell into them.
From experience I know only two pair programming roles: the do-er and the yes-man. Which one you are largely depends on the mood of both and the dynamic of the team. So either you're writing code while explaining what you do to your copilot, or you're the copilot who's basically just sitting there, pointing out the occasional syntax error. Now, conventional wisdom says this isn't how it's supposed to be, but I have yet to see a different dynamic in the wild.
One thing where I had good experiences regarding paired work was serious bug hunts. There, the most important part was the discussion and the constant back-and-forth of ideas was actually productive.
I haven't done much pair programming, but when I've been the co-pilot, I watch what is being written and think about what else needs to be done. If some critical thing gets missed, or I think the code isn't going to do what it's supposed to, I speak up. (That includes syntax, but also logic.) I sometimes (rarely) make suggestions about refactoring or tests that need to be done.
I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)
The times I've done pair programming, the co-pilot has been a lot more active than what you describe. While the driver types out the details of a couple of lines, the co-pilot will look at the surrounding code, figure out what to do next, and keep a stack of things to be done (while still keeping an eye on the code being written). Once the driver is done, the co-pilot suggest the next little task. This might lead to a little discussion, which is great, because you have two people who are really into the code.
This has been pretty hard algorithmic work, though. No fleshing out hundreds of lines per hour.
Interesting. The one experience I've had with pair programming was also with non-trivial algorithmic stuff, and we had the same positive experience. I wonder if it's a more general phenomenon: "pair programming is for the hard parts" or something like that.
Even if that were all that happened, it would still be a more efficient way of avoiding procrastination and sharing knowledge within the team than email and meetings. In my experience, though, the copilot often suggests simpler or less duplicative ways to do things, finds logic bugs rather than just syntax errors, and maintains state in their head that the driver would otherwise have to keep written down. I'm talking about my personal experience here, not how it's supposed to be.
I've also had good experiences in situations where the two parties bring different skills to the table. If, for example, person A really understands the back end algorithm that you're trying to implement and person B really knows the front end codebase you're trying to add that algorithm to. Or if person A really understands the math and person B really knows the programming language. Basically if the two people have more or less well defined roles within the team.
You are always expendable and can be shoved around like an animal, especially if you are a true team player that always nods and smile are "the best" to pair up with.
In fact, the cowboy programmers still rule the programming session when you pair up with them and they can easily take up most part of the day arguing small uninteristing details until they get it their way making the software theirs - not the team.