Effective Pair Programming

Imagine you had an angel (or demon) on your shoulder talking you through debug sessions

I used to love playing video games when I was a lot younger. My favorite genre was adventure. My brother and I would take turns controlling the main character while the spectator would call out pitfalls, and rewards and just provide emotional support.

Imagine my surprise learning to code and finding pair programming. For the avoidance of doubt, this post is about PAIR programming (not PEER programming), which describes a scenario where two or more software engineers, write code somewhat together to solve a problem or generate a solution. The premise being that two heads are better than one and it's always fun when there is more. Pairing is not native to programming btw, motor sports drivers have spotters, marksmen have spotters, doctors do ward rounds and Batman has Robin.

Why we Pair

Considering the premise of two minds on a problem, it should be more than clear that there would be some obvious benefits of accuracy, knowledge sharing, better focus, and probably increased efficiency … right? So why don’t companies and engineering departments encourage pair programming one might ask? Top of mind?

Diminishing returns: the cons seem to outweigh the pros fast, and the overall benefits are realized in medium to long-term spans.

The question then should be “How can we structure our pair sessions to bring out the best of pairing? “

Before attempting to answer this question, I will tell you a bit of a story on the background of this article and try to classify types of pairing, just to give all this knowledge a base to sit on.

A few weeks ago, a colleague and I had to harden our off-ramp systems against all the rigmaroles that we had been experiencing from our country’s abrupt adoption of a new cashless policy. The rails on which most financial products in Nigeria sat on were apparently not built for all that (new) traffic and as you would imagine, this congestion led to transaction failure and increased off-ramp times. Our product offers some of the fastest off-ramp times in Africa and we wanted to maintain our user experience. So we decided to fix this problem by introducing redundancies. Typically, this is a 1–2 week project, but we didn’t have the liberty of time. We decided to cut 1 week into 3 days. I paired with this colleague every day over a three-day period and we met our objective.

There are obviously different types of pair programming:

• The Driver/Navigator: One engineer writes the code while the other reviews and provides a bird's eye view perspective.
• The Ping-pong: Popular in TDD, one engineer writes tests and another engineer makes the tests pass
• The Unstructured: Either programmer takes on their roles as needed and the role-playing is rather flexible.

Now to our question, How does one derive the best-case scenarios from every pairing session?

1. Understand why you need Pair Program: It is relatively easy to “lose” focus during the call*. Pairing calls quickly tangent off into social calls and so it is helpful if the reason for pairing is clearly stated before the session begins. Properly define the problem being solved and why pairing helps you get over the line.
2. Set meaningful and achievable goals at the beginning of the session: This expands the initial thought of setting reasons for why the session is happening and it sets metrics for measuring the success of the pairing session.
3. Show up prepared: Every participant should be a “supplying joint”. Pairing should be like doubling compute on a given problem. If parties show up unprepared, the goal of concurrency is defeated as the unprepared parties become dead weight.
4. Use time blocks: It is easy to get carried away solving furiously at a problem. However, fatigue will set in sooner or later and overall team health will begin to suffer and hurt productivity. Too much of everything is bad. On the other hand, the premise that the pairing session will stay on topic if it is open-ended is somewhat false. Refer to point one.

I hope these few reasons and tips, incite and help your next pairing session. Long live the Software Engineer.