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.
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.
Imagine pair programming the first time it happened. Alice wandered over to Bob’s cubicle and said, “Hey, let’s work on this FORTRAN together.”
All right, so that little story might be apocryphal, but imagine how it might go. Alice and Bob are used to programming as a solitary pursuit, decide to put their heads together one day. They don’t necessarily know any techniques for programmer collaboration, so they wing it and try to help each other.
That qualifies as the first collaboration paradigm I’ll list. If that seems fatuous, you’re missing the lesson here. Knowing some techniques to try, definitely helps, but don’t paralyze yourself with analysis. If you want to get started, trial and error can go a long way. Just as the pairing techniques below evolved via trial and error, your own need to as well.
But also understand that limits exist to what constitutes pairing. It involves two checked-in minds and a single computer, so you are programming while your partner checks her email doesn’t qualify. But your technique can vary according to taste, using questions like “One keyboard or two?” and “Who types and when?”
In terms of established styles, let’s look first at driver-navigator. This arguably constitutes the most established style.
It derives its name from the way two travelers might negotiate a car trip through unfamiliar territory. The driver focuses on tactical concerns related to the mechanics of the activity. This includes operating the gas and brakes, turning the wheel, and keeping an eye out for obstacles and other cars. The navigator, on the other hand, thinks more about the big picture. How long will we be on this highway before we need to exit? Does my phone warn me of any unexpected traffic jams?
Apply the metaphor to programming, and the driver handles typing, navigating between files, and basic implementation. The navigator, on the other hand, looks at broader concerns and checks for mistakes. Does this method fit with the architecture? Are we potentially duplicating an implementation from elsewhere? Are we in a blind alley?
Driver-navigator works quite well with two experts, who may trade roles. It also works nicely with an expert and a novice. This happens most easily when the expert navigates because a novice navigator might sit passively while the expert fills both roles.
Next up in our pair programming styles, consider the backseat navigator. This protocol looks like driver-navigator but with the navigator taking over more of the tactical as well as the strategic (reminiscent of a backseat driver).
Like driver-navigator, the driver sits with his hands on the keyboard and executes the mechanics of typing and such. But unlike driver-navigator, his partner dictates tactical instructions. This might mean that she tells the driver when to create a method or open a new file. She might also tell him what to name a test or a variable.
This style works best with novice-expert pairings with novice as driver. It gives the novice a chance to learn by doing things the way the expert would.
Another style that works best with expert-novice is the tour guide. Again, the driving metaphor helps a good bit here.
Think of going on vacation somewhere and taking a local tour. The driver climbs into the van or bus, starts driving, and tells you about everything he’s doing and about everything that you’re seeing. You have a very passive role.
So it goes with the tour guide pair programming protocol. The driver does the strategic and tactical thinking, along with the typing. As she does this, she tells the “tourist” about what she’s doing. The tourist rarely intervenes.
This works with expert driver and novice tourist, particularly in cases of a brand new novice. But it also can work well flipped. Sit a novice down and let him flail at the problem a bit while an expert observes. The expert then provides feedback and correction, and they repeat.
You can’t complete a serious study of pair programming styles without looking at ping-pong pairing. This style has an interesting differentiating factor from the rest.
To understand, consider that pair programming comes from the extreme programming movement. Those folks love pair programming as well as certain other practices, such as unit testing. So when you encounter an extreme programmer, you can safely assume that she likes to pair and likes to practice test-driven development (TDD).
The cadence works simply enough. The first person writes a failing test and the second person gets it to pass. Then the second person writes a failing test and the first person gets it to path. Back and forth, back and forth. Kind of like a game of ping pong.
This style works exceptionally well with two experts (particularly when that expertise includes TDD). It also goes quite smoothly with the novice-expert pairing. And interestingly enough, it might go best with novice-novice pairing, when the goal is getting the novices some practice. All of these go so smoothly (notwithstanding any interpersonal issues) because the two switch roles so frequently as to think together constantly.
I’ll close by offering a sort of “unofficial” pairing model. But this pairing model likely holds the key to the future in an increasingly global, distributed world. I’m talking about distributed pairing.
Extreme programming got its start in the 90s. At that time, remote work involved Citrix and dial-up modems. In other words, you didn’t do collaborative programming work anywhere but in person. But fast forward 20 years, and the mandate for colocation has subsided with the rise of technology. You can use something like Screen Hero to collaborate pretty seamlessly. Obviously, in-person collaboration still happens more efficiently, but technology has seriously closed the gap. And the logistical benefit to letting people collaborate from anywhere is undeniable.
I believe the future of pair programming styles will involve the tried-and-true techniques. But I think the distributed one will get more than a single section. The preceding sections involve techniques that people have created and refined over time. In 20 years, I suspect that we’ll see some pretty clever and sophisticated remote pair programming styles.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
