Three tenets of pair programming

I was just reading some articles on TechCrunch about pair programming and its pros and cons. This is the kind of subject it seems you have either tested and love it or think it sounds weird and will never even try.

I have done it myself in different constellations over the last couple of years and would summarize it like this; if done correctly, it is so much more powerful than the sum of the participants.

So, according to me, how do you pair program correctly? Reader discretion is advised - personal opinions to follow.

The first criterion is that both participants should be near equally skilled. If there is too much difference between the two, either the senior will feel held back and never gain momentum or the junior will get lost and be unable to contribute. It can still be a good way to spread knowledge in a team but be sure to watch that motivation meter!

The second criterion concerns the problem subject. It needs to be complex enough to benefit from having two brains working on its solution. Reading up on a subject before working on it or doing simple monkey programming are both aspects of software development and neither are suitable for pair programming.

Third and finally I believe it is vital to switch roles and have the participants take turns to be driver and navigator. This is a sin I frequently commit myself, because I can not type on a Mac keyboard or my partner gets lost in Vim or whatever other practicality reason comes up. Switching roles widens your mindset and you do not want to miss out on this.

So to recap. Two developers with similar skills, working on a complex enough problem and whom takes time to configure a common work environment up front - that is a recipe for quality software.

Published