As the title alludes to it, this article is about why bother with pairing? I think there are three primary reasons: Better Collaboration, Higher Quality Work, and Learning. I’ve been pairing for almost 6 months now at work, and for the most part I’ve found it highly beneficial. We take about a 60/40 or 70/30 split of solo work to pairing work. The most important features/work are usually done in pairs.
I’ve noticed my work relationships have improved thanks to pairing. Little things, like oh we should ask this person this question become less about are you “afraid to talk to them” and more “is this faster than not talking to them”. I’ve also had my pair point out work decorum things I hadn’t been doing. Specifically, don’t work around someone as you will likely piss them off in the process. Even if its currently painful, you have to go directly to them. That’s the only way the work relationship will improve.
The collaboration not only helps in regular communication, but in figuring out what to do on the feature. Is this feature design correctly? Is the architecture correct? Are we tackling this correctly? Does this code belong here? All of these questions are better answered either by rubber-ducking with your pair, or better yet collaboration with your pair.
I’ve found the work quality of what is produced in a pair is much better. On a team without pairs you tend to work to the lowest common denominator. Is John going to understand this concept? If I write code in this way, will John screw it up? I use John as the name as I cannot think of a programmer named John, and kind of in jest (I once had a best friend named John). At any rate, in the pair whoever is doing something better, the other person naturally wants to learn the better way. This ingrained learning isn’t forced, and you get to pick things up naturally.
These pairings have a very different feeling than senior/senior. I can only speak to this from the viewpoint of the senior programmer. Mostly, I noticed I’m sort of “forced” to slow down as the less experienced person doesn’t absorb the information as fast as I’d like too. Maybe its a weakness I have of trying”go fast” as well. At any rate, slowing down and explaining things I’ve noticed has its own value. It forces you to put into words the ideas in your head. Sometimes you realize “oh shit, the way I thought about this makes no sense”. Other times you realize the reasons for your thinking, or can better clarify the strengths of a particular method.
To me this is where I get more benefit out of the pairing. What does this particular senior engineer do better than me currently? What can I learn from them? I start to realize my “weakness”, but often one person’s weakness is actually just another person’s “strength”. There is still a teaching aspect to this as well, as you learn how to “properly” pass on knowledge to others. Do I directly tell them? Do I show them repeatedly how I go about doing the task? The lucky thing in pairing is that you get to try all of the above.