This post is part of a series:
- Introduction
- The Good
- Individuality And Creativity
- Code Quality
- Odds & Ends
For the past year, I've been working in an environment where pair programming is strictly enforced. This is the first post in what will most likely become a series of blog posts where I collect my thoughts on pair programming.
Some Background
I've had a curiosity about pair programming since first falling into the Agile methodology material and the XP value system. Further research on the subject led me to many blog posts that re-asserted it benefits: shared code ownership, less defects and higher code quality, etc. I found almost no material providing negatives of pair programming other than the occassional article about how it results in less lines of code written by management types. Since I'm not a manager or in any way in charge of signing someone's paycheck, the amount of code a developer produces has never been a compelling argument to me one way or another. And I won't be covering that aspect that in this series.
About a year and a half ago, I interviewed at a company whose developers practiced pair programming as part of their every day working arrangements. I received an offer but turned it down, partly due to the compensation and benefits package being less than ideal, but also because I got cold feet about the prospect of pair programming. It scared me.
A few months later, I interviewed at yet another company who also practiced pairing and this time, I accepted the position. I really wanted to give it a shot. Up until that point, I'd been developing software in mostly the same way for my whole career and I felt like this would be a great change of pace. I came into it hopeful that my lingering doubts were based on fear of change and that the experience would be very beneficial.
After a year of pairing, I can confidently say that pairing is not for me. Let me reiterate: it's not for me. I chose those words very carefully. This isn't blanket advice to pair or not to pair. I think there's too much prescriptive advice in our industry. Instead, over the next few posts, I will get into the good and the bad of pair programming - with the very obvious caveat that its all from my perspective. Because one thing I do have to thank pairing for is the experience. It has helped me realize how I am most creative and productive. The old saying "you don't know until you try" applies here. I credit pairing with helping me realize what things are important to me in my personal creative process.
So let's get into it... first up, let's talk about where pair programming is good.