Why pair programming works

Written by

Walter G.

Published on

October 24 2019

Modified on

September 25 2021

Filed under

programming

Coding for the most part is a one person job. Many lines of code, many modules, but you can only work on one module at at time by yourself. The idea of pair programming isn't a relatively new concept or even solely related to coding really. Rally car racers have navigators right next to them with an outline of the course guiding the drivers through ancient forests and snowcaps at 100 mph. And boat captains similarly have (or had) navigators keeping an eye out for land and such using fanciful telescopic devices.

Similarly, with pair programming, you have both of those roles in action. You have a driver (programmer) and a navigator (also a programmer). The navigator has the following roles to play, which are very important:

- reads the code
- looks at the notes
- takes notes
- brings up questions
- points out bugs
- offers subtle encouragement
- keeps the programmer from getting distracted and surfing the web
- refills coffee (sometimes?)

While the programmer has the following role:

- code
- listen

Every so often, both roles will switch to give the programmer a break as coding does require a certain level of focus and energy and doing so for hours on end can definitely lead to mental fatigue or burnout.

Why it works

In my opinion, pair programming is a great tool to use under one particular circumstance. Mainly, if the project in question is complicated. Imagine the following if you will:

You are building a car engine, but have no idea how, but the tools and parts are right in front of you. Just deciding which tool or part to pick up first will take hours and needless stress and anxiety will ensue. So you introduce one more person into the equation to help out. Now you can ask questions, make suggestions and the anxiety is reduced by large quantities allowing for a smoother overall process. You might still not be able to build an entire engine, but you will probably get much further than you thought possible.

Now let's go into the more subtle reasons as to why pair programming is a highly functional methodology that does not get used enough in my opinion.

Increases focus

Coding involves hundreds of micro-adjustments and pauses per hour in order to get something up and running. We don't notice these interruptions, but they are there. Pay attention next time you are knee deep in coding something and notice how every couple of lines you'll pause to test the code or to ponder if it makes sense. 2 very important things for sure. But they take up time.

And this is where the navigator steps in, because they are offloading that work from you and are already a few steps ahead ensuring that you don't lose that precious focus.

Shared responsibility

Having a tight deadline, a complicated project and being solely responsible for the whole thing is stressful. If you want to know how stressful, read my post on coding and stress right over here.

Pair programming helps to alleviate that stress by splitting up the responsibility between you and your partner. You still have to meet your deadline, sure, but now you are not alone. Someone else knows exactly how you feel and you can both discuss the pain points and try to find ways to catch up.

This even trickles down to management. If 2 people can't seem to meet the deadline, then perhaps the project was planned poorly from the beginning and in future projects these things can be adjusted.

Potentially less bugs

One of the biggest causes for bugs in the coding profession is the lack of communication between the various connected elements. By that I mean, the members of your team. For example, say you are working on a new sales management system for your company. Your lead developer designed the database, set up the framework and created some tasks for the team to work on. The designer began work on creating fanciful creations from their mind, which the front-end developer will split into multiple HTML elements along with the required CSS/JS. And you (the coder) will begin work on retrieving data from the database and making sure that the buttons do what they are suppose to.

If at any point someone in that chain misinterprets a task or an understanding of how something works, then it will trickle down to everyone that follows. While you can't pair program with the entire team all at once (would be weird), simply chaining up two people together will reduce the possibility of this happening, or at least of someone spotting a potential error before it becomes a bigger issue.

Increases communication

You might have a tight lunch group that you hang out with every day, but that doesn't mean that you can work together as a cohesive unit of coding professionals. Communication is not a natural consequence of being human for the most part. It takes practice. Years of practice in fact to be able to both understand what another person is saying with as high accuracy as we can muster and to speak in a way where people understand us.

This is why every first meeting with anyone whether a classmate or a manager is always stressful. We don't know what to expect from this person and so we use the first few sessions to build a model of who they are. By the second or third meeting working however you are both more in tune with each other and communication becomes much smoother.

It's still a challenge to find employers that openly promote the practice of pair programming. Programming is still seen as a one person job, and that's because for the most part it is. Not every project that you work on will be a complex and challenging venture and require multiple brains to tackle.

But it is definitely a valuable tool to keep in mind when taking on that next big challenge, either for yourself or an employer.

Comment down below if you are a fan (or not) of the practice. And if not, let me know a few reasons it's gone south for you.

Comments

No messages posted yet

Add comment