I agree that pair programming has it's place and can be a positive workflow for some, but for the way I work I just find it extremely intrusive and I easily get a third of what I would get done. I'm a big advocate of peer reviews, but pair programming just takes me out of my workflow and impairs my creativity and performance.
In my work environment I find "pair programming" to be useful the 5% of the time someone is working on a Hard Problem. Most time during the work day is UI tuning, debugging, and generic implementation of straightforward features.
Pair programming doesn't need to be a policy because it precipitates naturally out of someone asking for help on a Hard Problem. That 5% of the time you're working through a tasks key algorithm, or discovering the best User Interaction for a complex feature.
I find Pair Programming to be a important sounding label for something which is actually quite mundane. It's called working together™.
It's a waste of my time to sit and watch someone implement the 95% of software that is mundane.
I agree with your dislike for relabeling the mundane, but "pair programming" is used to indicate a specific form of collaboration which includes the the three points mentioned in the post.
The sort of collaboration you're referring to is what I'd call brainstorming. Pairing with someone only for brainstorming purposes would be wasteful.
First, let's agree on the definition of mundane as used here. To me, your use of mundane suggests the task of writing a program after high-level questions, what and why, have received high-level answers. Everything but initial brainstorming.
The hypothesis introduced in the article is that pair programming is beneficial because it improves individual skills and code quality. I'm not sure how clearly that's communicated.
Individual skills are improved by understanding your current problem-solving process and upgrading it as necessary. This isn't only about picking up skills by observing others, but reasoning about the steps you take and updating as appropriate. Pair programming isn't necessary for this, it just facilitates it. This whole being mindful thing deserves a post of its own.
I would expect that code quality would be improved because design flaws and bugs are more likely to be caught early. Therefore there's less time spent rewriting or debugging.
I'm treating this foray into pair programming as an experiment. It was literally a week ago that I began to see how pair programming could be efficient and even enjoyable. I do not plan on doing 100% pairing forever, it's impractical and probably inefficient. Right now I'm thinking that 50-75% pairing might be an optimum in most cases.
If you are paired with the right person I believe this has the potential to drive you forward and keep you motivated. I experienced pair programming when I was still studying.
We had a lot of team assignments and when I worked with my best friend, instead of splitting the work like most of the other students, we just sat both in front of one computer and went through all of it. The one guy writing the code is always getting double-checked by the other guy and that way you eliminate most of the little bugs that slip past your judgement when you code alone.
Certainly a most enjoyable method of programming, although whether it is an economically viable strategy I could not tell.
On my dayjob we did some experiments on wether or not it was economically viable. So we tried classical programming and pair programming. We found that classical programming was more productive, but not twice as productive. However there were a lot less bugs found after an iteration of pair programming. When we factored that in, pair programming did end up being the better choice.
Like 10 years ago my best friend and I used to sit at the same computer and do the coding and UI design together! It was not all the time but it was a significant part of the day. We were developing mostly ASP pages and he was the UI designer and I was the backend coder and it made sense to go do our part then get together and merge them and then go back to do our part again. I really miss that time very very productive we were.
