Eliminating DialectsIf you asked 10 people to write a small paragraph about a specific idea, you would probably get 10 very different results. In fact, this would likely be true even if you specified exactly how you wanted them to write it (everything from how many sentences should be used to which grammatical structures to allow). Same is true for programmers. Devs have their own unique styles of writing code, no matter the language. They differ on variable and method names, preferences for specific control flow constructs, commenting styles, etc. In short, devs have their own unique dialects. These dialects are especially noticeable when a single dev works exclusively on a specific part of a large code base. Reading different modules in such a code base is like going on a cross country tour and hearing everything from a Texan twang to a Noo Yok accent. Sure, there are things you could do to try and minimize these differences (things like coding standards and naming conventions). However, I find that most devs have a hard time following naming conventions when left to their own devices. It’s just too easy to slip into your dialect when no one is looking. Enter pairing. Pairing is almost surprisingly effective at eliminating dev dialects and getting the code base to read as if written by a single programmer. Apparently, it’s a lot harder to inject your own style into the code when someone else takes over the keyboard every few minutes.
Reducing ComplexityToo many devs love complexity. More troubling, too many feel compelled to needlessly introduce it into the code they write. Most troubling of all, too few have the self-awareness to realize what they’re doing before it’s too late. So, code bases everywhere are littered with various versions of a Goldberg machine. The thing is, when the code is only in your head, it usually sounds very straightforward. Boundary conditions and edge cases are glanced over, weird leaps of logic don’t appear quite so weird, complex constructs seem simple, and so on. Pairing forces you to explain your seemingly rational design ideas to another human being. Most of the time, the very act of explaining it to someone else helps you realize that something is off. And if that doesn’t do the trick, a puzzled look or a skeptical “OK…” from your pair probably will.
Final ThoughtThe two most commonly accepted reasons to pair are promoting shared ownership and forcing continuous code reviews. These are important benefits to be sure, but paring helps in other ways as well. Have you noticed any you’d like to share?
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!