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.
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.