Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, check out their products that help you wrangle production issues in a hurry.
The world of professional programming produces some pretty intense debates. For example, take a look at discussions about whether and how to comment code. We have a hard time settling such debates because studying professional programming scientifically is hard. We can’t really ask major companies to build the same software twice, using one control group and one experimental group. So we muddle through with lots of anecdotes and opinions and relatively scant empirical data. Because of this conundrum, I want to talk today about pair programming styles rather than taking a stance on whether you should pair program or not.
I’ve talked previously about the benefits of pair programming from the business’s perspective. But I concluded that post the same way that I’m introducing this one. You can realize benefits, but you have to evaluate whether it makes sense for you or not. To make a good evaluation, you should understand the different pair programming styles and how they work.
That’s right. Pair programming involves more than just throwing two people together and telling them to go nuts. Over the years, practitioners have developed techniques to employ in different situations. Through practice and experimentation, they have improved upon and refined these techniques.
The Effect of Proficiency on Pair Programming Styles
Before looking at the actual protocols, let’s take a brief detour through the idea of varied developer skill levels. Although we have a seemingly unique penchant for expressing our skill granularly, I’ll offer just two developer skill levels: novice and expert. I know, I know. But those two will keep complexity to a minimum and serve well for explaining the different pairing models.
With our two skill levels in mind, consider the three possible pairing combinations:
Now when I talk about expertise here, bear in mind that this accounts for context and not just general industry experience. Tech stack, codebase familiarity, and even domain knowledge matter here. I have two CS degrees and years of experience in several OOP languages. But if I onboarded with your GoLang team tomorrow, you could put me safely in the novice camp until I got my bearings.
Each of these pairing models has its advantages and disadvantages. Sometimes, however, fate may force your hand, depending on who is available. Understanding the different pairing models will help you be effective when it does. It also bears mentioning that novice-novice pairings offer a great deal of learning for both novices, but with risk. Therefore, the suitability of such a pairing depends more on your appetite for risk than the pairing model.