Do you like pair programming? I tried it and I liked it.
Since May, I’ve been working in a team where we regularly do pair programming. This is my first experience with extensive pairing. We aren’t anywhere close to 100 %, but even doing a couple of sessions per week is way more pairing than I’ve ever done before. In general, it has been a positive experience.
Pairing is at its best when both of you unsure about what you’re doing. Having someone there helps a lot when you’re trying to figure out how something should work.
My favorite sessions have been the ones where we write the SQL for the data model of our greenfield application. Even though we’ve sketched the data model beforehand, there are always some small problems that you have to think through.
Pairing also works well when one of you is unsure about what you’re doing. That person should then “drive” (i.e. write the code) while the more knowledgeable person guides them. This seems like a good way to share knowledge.
Pairing is less useful when both of you know what you’re doing. The person writing the code does not really need help or guidance. There’s not much to do for the other person.
Pairing is intensive. I can do it only for two hours or so and then I need to do something else. I expect this to change with time, but right now I have hard time imagining pairing full-time.
While I’ve enjoyed pair programming, I find pair debugging frustrating. My working style when I’m debugging does not suit pair work: I concentrate intensely, jump quickly around, and rely on my intuition. This is not helpful for either driving or guiding. My friend Mikhail pointed out that maybe I should consciously focus on helping others to debug instead of solving the problem. I have not yet tried this.
Pairing and code review
Pairing and code review have similar benefits. They both increase cohesion and spread knowledge of the code base. They also help at improving the coding skills and catch bugs and quality issues.
I have a lot of experience with code review and would recommend it for almost any project except short-lived prototypes. It’s worth it for the knowledge transfer alone. My updated recommendation is that if you use pairing, you do not necessarily need code review – you already got most of the benefits with pairing.
My rule of thumb is that all code should be engaged with by (at least) two persons. To achieve this, we mix these practices: some code is written by pairing and the rest of it goes through code review.
I’m happy that I have a new, robust tool for producing good code in my toolbox. If you haven’t yet tried regular pairing, I recommend giving it a go.