I've never pair programmed, but I'm not sure I'd like it. As much as I like collaborating, I prefer alone time to work on problems, or think things through and experiment a bit on my own. I prefer brainstorming and discussion sessions to be limited in nature, with the chance to then go work on my own pieces along.

However pair programming has been touted as a way to improve software quality by many people. It's not as popular as some other methodologies, but it still exists out there. I ran across a programmer's reflections on nine months of pair programming that made for a thought provoking read. He looks back at the experience and lists some pros and cons. Better code, more productivity, and lots of knowledge transfer were some of the positives, and would lead many managers to try and push developers into working in pairs.

However there were downsides. As someone that speaks regularly, I think that the strain on my vocal chords would be hard if I had to speak constantly to someone else. The fact that the environment needs to be consistent for both people would also be a problems as I often find strong opinions from  developers in technology as to how they want an environment configured for their tasks. I know that watching someone else control a browser drives me a little crazy. I think I'd definitely need to have a separate machine for many tasks.

As with anything, pair programming makes sense at times. I know that I'd like to have senior T-SQL coders work with junior ones when developing complex queries and explaining how and why they solve problems with certain techniques. Doing this in real time might slow down the senior person, but I think the evolution of one's thoughts as they solve a problem is as important to learn as the inner workings of the actual code.

The Voice of the DBA Podcasts

We normally publish three versions of the podcast each day for you to enjoy. Today there is no podcast due to Steve being ill. Hope to have the podcasts return tomorrow.