Pair programming is the practice of working alongside another developer on the same task; the key advantage is simply that two brains are better than one. Following it formally requires the pair to assume the role of a driver and observer, each with key functions. While the driver is typing, executing tests, and so on, the observer thinks about the strategy behind their approach to the work. Because the different roles exercise different mental muscles, it’s useful to switch roles relatively frequently. In my opinion, there are some fascinating intangible benefits gained from this practice.
Because both developers worked on the task together, there is a deeper shared understanding about how the edited subsystem works, integrates into the rest of the codebase, and why this particular direction was chosen. In doing so, the team is actively reducing the vacation or lottery factor. Speaking from experience, it’s terrifying to be the sole owner of particular knowledge about a system.
Having two people working on the same task sounds like a waste of resources. In theory, those two developers could accomplish twice the work in parallel over the same amount of time. In practice, there are significant differences between code written by a single developer and a pair, especially as the uncertainty, ambiguity, and/or complexity increases on an issue. Tests are often more complete because one person can be focusing on the implementation while the other can be focused on testability. Code reviews are almost always smoother because in some respect, the work has already been reviewed. Go fast by slowing down, as they say.
Pairing a senior and less-experienced developer together is one of the purest forms of knowledge transfer that I’m aware. Obviously, the senior can rely on experience to help guide the pair towards the better solution, understanding what pitfalls look like before they take a wrong turn. The senior can also demonstrate usage of tools, for example how to more quickly invoke the test-suite through a keyboard shortcut.
However, I think there are many things the less-experienced developer can also contribute. I’m always very interested in what growing developers don’t understand because it reveals to me areas to focus on when teaching. If there’s a gap around a 3rd-party library, it might make sense to pause the main work and write a few tests (that will likely get thrown away) to increase understanding of how that library or framework is working. But when the less experienced colleague doesn’t understand something about the domain and/or our model of it, then clearly I haven’t done enough as a team leader to document and share these design decisions. Finding and filling these gaps in knowledge is some of the most useful work we as senior team members can perform because it compounds over time, as the now-less-junior team member is more capable of independent work and guiding others.
Group riding, as I’ve come to know it, is not much different. First and foremost, it allows you to pit yourself with more advanced athletes that can push you in ways simply not possible by yourself alone. If the advanced rider sets the pace and route, the less-experienced rider can then observe improved shifting, braking, and cornering techniques. Just as above, by not leading, we can focus on learning the skills to make us a better leader.
Communication as a solo-rider tends to focus externally. Most importantly, we must be communicating our position (with lights, reflective clothing, etc) and our intentions, hand-signaling to cars about approaching turns. With a group of riders, however, we must work to communicate both the state of the road (debris, potholes, etc) and nearby traffic (for example, it falls to the rider in the rear to call “car-back”, signifying an automobile is approaching the group from the rear).
These are things that you understand on a solo ride and are constantly thinking about. By needing to clearly communicate when riding with others, it forces more intention and attention. We pay more close attention to our surroundings, signaling towards potential danger. We’re intentional about this because we can never assume another rider knows what we know. After all, nobody has ever said “I wish you hadn’t told me about that dangerous car that flew past us without warning”.
The same goes when programming as a pair! It is brash to assume a colleague knows particular minutiae (and we certainly never want to feign surprise). We aim to clearly demonstrate our understanding of the world so that it may help another build a more clean mental-model for themselves. And if (but really when) your partner has something to teach, listen and incorporate it into your own worldview.
Above all, work to find those people with which you can learn and train, hopefully riding better together than you’d be alone.