The world of professional programming produces some pretty intense debates. \u00a0For example, take a look at discussions about whether and how to comment code. \u00a0We have a hard time settling such debates because studying professional programming scientifically is hard. \u00a0We can’t really ask major companies to build the same software twice, using one control group and one experimental group. \u00a0So we muddle through with lots of anecdotes and opinions and relatively scant empirical data. \u00a0Because 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.<\/p>\n
I’ve talked previously about the benefits of pair programming<\/a>\u00a0from the business’s perspective. \u00a0But I concluded that post the same way that I’m introducing this one. \u00a0You\u00a0can<\/em> realize benefits, but you have to evaluate whether it makes sense for you or not. \u00a0To make a good evaluation, you should understand the different pair programming styles and how they work.<\/p>\n That’s right. \u00a0Pair programming involves more than just throwing two people together and telling them to go nuts. \u00a0Over the years, practitioners have developed techniques to employ in different situations. \u00a0Through practice and experimentation, they have improved upon and refined these techniques.<\/p>\n Before looking at the actual protocols, let’s take a brief detour through the idea of varied developer skill levels. \u00a0Although we have a seemingly unique penchant<\/a> for expressing our skill granularly, I’ll offer just two developer skill levels: novice and expert. \u00a0I know, I know. \u00a0But those two will keep complexity to a minimum and serve well for explaining the different pairing models.<\/p>\n With our two skill levels in mind, consider the three possible pairing combinations:<\/p>\n Now when I talk about expertise here, bear in mind that this accounts for context and not just general industry experience. \u00a0Tech stack, codebase familiarity, and even domain knowledge matter here. \u00a0I have two CS degrees and years of experience in several OOP languages. \u00a0But if I onboarded with your GoLang<\/a> team tomorrow, you could put me safely in the novice camp until I got my bearings.<\/p>\n Each of these pairing models has its advantages and disadvantages. \u00a0Sometimes, however, fate may force your hand, depending on who is available. \u00a0Understanding the different pairing models will help you be effective when it does. \u00a0It also bears mentioning that novice-novice pairings offer a great deal of learning for both novices but with risk. \u00a0Therefore, the suitability of such a pairing depends more on your appetite for risk than the pairing model.<\/p>\n <\/p>\n Imagine pair programming the first time it happened. \u00a0Alice wandered over to Bob’s cubicle and said, “Hey, let’s work on this FORTRAN together.”<\/p>\n All right, so that little story might be apocryphal, but imagine how it might go. \u00a0Alice and Bob\u00a0are used to programming as a solitary pursuit, decide to put their heads together one day. \u00a0They don’t necessarily know any techniques for\u00a0programmer collaboration, so they wing it and try to help each other.<\/p>\n That qualifies as the first collaboration paradigm I’ll list. \u00a0If that seems fatuous, you’re missing the lesson here. \u00a0Knowing some techniques to try,\u00a0definitely helps, but don’t paralyze yourself with analysis. \u00a0If you want to get started, trial and error can go a long way. \u00a0Just as the pairing techniques below evolved via trial and error, your own need to as well.<\/p>\n But also understand that limits exist to what constitutes pairing. \u00a0It involves two checked-in minds and a single computer, so you are programming while your partner checks her email doesn’t qualify. \u00a0But your technique can vary according to taste, using\u00a0questions like “One keyboard or two?” and “Who types and when?”<\/p>\n In terms of established styles, let’s look first at driver-navigator. \u00a0This arguably constitutes the most<\/em> established style.<\/p>\n It derives its name from the way two travelers might negotiate a car trip through unfamiliar territory. \u00a0The driver focuses on tactical concerns related to the mechanics of the activity. \u00a0This includes operating the gas and brakes, turning the wheel, and keeping an eye out for obstacles and other cars. \u00a0The navigator, on the other hand, thinks more about the big picture. \u00a0How long will we be on this highway before we need to exit? \u00a0Does my phone warn me of any unexpected traffic jams?<\/p>\n Apply the metaphor to programming, and the driver handles typing, navigating between files, and basic implementation. \u00a0The navigator, on the other hand, looks at broader concerns and checks for mistakes. \u00a0Does this method fit with the architecture? \u00a0Are we potentially duplicating an implementation from elsewhere? \u00a0 Are we in a blind alley?<\/p>\n Driver-navigator works quite well with two experts, who may trade roles. \u00a0It also works nicely with an expert and a novice. \u00a0This happens most easily when the expert navigates because a novice navigator might sit passively while the expert fills both roles.<\/p>\n Next up in our pair programming styles, consider the backseat navigator. \u00a0This protocol\u00a0looks like driver-navigator but with the navigator taking over more of the tactical as well as the strategic (reminiscent of a backseat driver).<\/p>\n Like driver-navigator, the driver sits with his hands on the keyboard and executes the mechanics of typing and such. \u00a0But unlike driver-navigator, his partner dictates tactical instructions. \u00a0This might mean that she tells the driver when to create a method or open a new file. \u00a0She might also tell him what to name a test or a variable.<\/p>\n This style works best with novice-expert pairings with novice as driver. \u00a0It gives the novice a chance to learn by doing things the way the expert would.<\/p>\n Another style that works best with expert-novice is the tour guide. \u00a0Again, the driving metaphor helps a good bit here.<\/p>\n Think of going on vacation somewhere and taking a local tour. \u00a0The driver climbs into the van or bus, starts driving, and tells you about everything he’s doing and about everything that you’re seeing. \u00a0You have a very passive role.<\/p>\n So it goes with the tour guide pair programming protocol. \u00a0The driver does the strategic and tactical thinking, along with the typing. \u00a0As she does this, she tells the “tourist” about what she’s doing. \u00a0The tourist rarely intervenes.<\/p>\n This works with expert driver and novice tourist, particularly in cases of a brand new novice. \u00a0But it also can work well flipped. \u00a0Sit a novice down and let him flail at the problem a bit while an expert observes. \u00a0The expert then provides feedback and correction, and they repeat.<\/p>\n You can’t complete a serious study of pair programming styles without looking at ping-pong pairing<\/a>. \u00a0This style has an interesting differentiating factor from the rest.<\/p>\n To understand, consider that pair programming comes from the extreme programming movement<\/a>. \u00a0Those folks love pair programming as well as certain other practices, such as unit testing<\/a>. \u00a0So when you encounter an extreme programmer, you can safely assume that she likes to pair and likes to practice test-driven development (TDD)<\/a>.<\/p>\n The cadence works simply enough. \u00a0The first person writes a failing test and the second person gets it to pass. \u00a0Then the second person writes a failing test and the first person gets it to path. \u00a0Back and forth, back and forth. \u00a0Kind of like a game of ping pong.<\/p>\n This style works exceptionally well with two experts (particularly when that expertise includes TDD). \u00a0It also goes quite smoothly with the novice-expert pairing. \u00a0And interestingly enough, it might go best with novice-novice pairing, when the goal is getting the novices some practice. \u00a0All of these go so smoothly (notwithstanding any interpersonal issues) because the two switch roles so frequently as to think together constantly.<\/p>\n I’ll close by offering a sort of “unofficial” pairing model. \u00a0But this pairing model likely holds the key to the future in an increasingly global, distributed world. \u00a0I’m talking about distributed pairing.<\/p>\nThe Effect of Proficiency on Pair Programming Styles<\/h3>\n
\n
Unstructured Pairing<\/h3>\n
Driver-Navigator<\/h3>\n
Backseat Navigator<\/h3>\n
Tour Guide<\/h3>\n
Ping-Pong Pairing<\/h3>\n
Distributed<\/h3>\n