The Power of the Pair
By Ainan Ameen
Here at TribalScale, we believe that process is everything. We exercise this belief through a form of agile development known as Extreme Programming. Extreme Programming gets its name from the idea of taking the practices of traditional agile development to the “extreme”. One of the fruits of this methodology is pair programming.
Pair Programming Explained
In short, pair programming is when two software engineers work together at one workstation. The pair consists of the driver, who writes code, and the navigator, who reviews the code in real time. It’s the same paradigm as rallying, i.e. racing rally cars, where a co-driver sits in the front passenger seat and helps the driver maneuver the upcoming turns and obstacles. However, unlike rallying, roles switch frequently. Our workstations consist of two keyboards, two mice, and two monitors (which are mirrored to each other). This means that both engineers are viewing the same content and are able to take control at any time.
At first glance, pair programming seems inefficient. If two engineers are working on the same workstation, mathematically speaking, that’s half the amount of code written. However, the way we view software engineering is not by lines of code written, but rather as complex problems needing to be solved. The old adage of “two heads are better than one” applies here.
The Advantages of Pair Programming
Truthfully, I was skeptical about pair programming before joining TribalScale. That being said, it wasn’t long before I became a huge advocate of it. Here’s why:
High Quality of Code
The code produced from pair programming is of substantially high quality. Line-by-line code review in real time places each line of code under heavy scrutiny. Sure, you can understand your own code, but when you have another engineer to satisfy, you’re motivated to make it foolproof. Pairs then deliberate on the code written to determine whether it follows best practices. Due to diversity of knowledge, the chance of two engineers getting blocked on the same potential issue is far slimmer than one working alone. Last but not least, it annihilates any urge to cut corners during development.
Dissemination of Knowledge
Let’s take a look at the combinations of pairs. With a senior-junior tandem, it’s obvious that the junior engineer has the privilege of learning rapidly. Witnessing a senior engineer’s thought process and actions (e.g. keyboard shortcuts) when coding in real time is simply invaluable. But what’s overseen is how the senior engineer is able to solidify their understanding of the material when being bombarded with questions along the way. When pairing with someone of the same skill level, you’re constantly being challenged, having to question everything, and solving problems as a team. Moreover, when adding more engineers onto a current project team, the working pairs can split up and ramp up the new engineers more effectively. Overall, knowledge transfer is seamless through pair programming.
In my humble opinion, the social integration aspect is the “secret sauce” of pair programming. Software engineers unfortunately share the stigma of being anti-social or lacking proper communication skills. With pair programming, communication skills are practiced as much as engineering ones. Everyday, pairs are solving problems together, building a work culture that’s based on foundations such as teamwork and conflict resolution. Not only do these qualities impact how valuable you are at work, but they also help in your everyday relationships and social interactions. The social integration aspect makes work more fun and enjoyable, which is pair programming’s most valuable asset.
Pair programming is a multi-dimensional practice that does more than forge exceptional code. It brings out the best in your software engineers and your company. If I haven’t convinced you yet, go give it a shot. I promise you that you will not be disappointed.