Pair Programming Might Be Great
posts.dynamictyping.org
posts.dynamictyping.org
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.
The sort of collaboration you're referring to is what I'd call brainstorming. Pairing with someone only for brainstorming purposes would be wasteful.
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.
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.