Pair programming: How to get the most out of it?

Years ago, at Redsauce a software company, we ventured into some projects that we might call "ingenious craziness." We made many mistakes, but also many successes. It's curious how nostalgia works: the vehement phone discussions about problem implementations that consumed us become legendary analysis experiences whenever the obtained solution stands the test of time.

And always, around this success, there was something common, once inexplicable, to which eventually an internet search put a name: pair programming.

The concept of pair programming is very simple: two minds, one program. One person controls the mouse and keyboard, the other observes, asks questions, and offers solutions, switching roles every 20 minutes.

That internet search ended up confirming what experience already suggested: it doesn’t work with one or three. It has to be two, and you have to follow the pair rules.

The rules of pair programming

The right amount of time

Limit to 1-2 hours daily with breaks, avoiding exhausting your mind and your partner's. After 25 minutes, attention drops drastically, so I recommend not doing more than 30 minutes in a row. This practice is especially relevant in projects involving qa testing, performance testing or web automation.

Choosing your partner

Choosing the right partner is one of the most complex things in life. In small companies, it’s difficult because there isn’t much staff available, but if you’re lucky enough to choose, look for similar levels of experience to avoid imbalances and foster mutual learning, especially in areas such as async javascript or bdd (Behaviour Driven Development) using tools such as gherkin cucumber.

Punctuality

Be punctual with your partner. We’ve all worried about having a meeting and our partner not arriving on time or not notifying us. Above all, avoid writing code without your partner’s presence.

Existing code

If your partner has already written code, it’s better to tackle new areas or discard that code and start over. The idea is for the code to consider both people’s ideas, not for one to write the code and the other to receive an explanation to understand it.

Active participation

Both of you must contribute to the code equally. If not, the pair won’t work.

Together until the end

In one way or another, time puts an end to all partnerships. But while it lasts, never separate the work. Treat your algorithms as your own child. Smooth out its rough edges. Be proud when everything goes well. Both of you must participate in its development equally.

The promised fruit of pair programming

It’s very important to check the result of pair programming compared to solo programming. This can be done, for example, by counting the defects found in the code written in each way, the number of times a code review requests changes, or the implementation speed.

In our case, the code we obtained through pair programming was of much higher quality, well-documented, worked well in extreme cases, the experience of both people increased by learning each other's techniques, and above all, a tangible reduction in the inherent sadness of solo programming.

With these pair programming practices, we discovered that the solutions to a problem are as diverse as the people who implement them. No solution is perfect on its own, but by combining them all, uncertainty turned into fun, boredom into ingenuity, and the final result was usually spectacularly good.

Not everything is magic in pair programming

However, when a pair doesn’t work, the result is terrible. There’s deception, each one operates on their own, no one understands anything, and the code makes you lose the will to live just by reading it. It’s as important to follow the pair programming rules as it is to detect that the pair isn’t working, and in that case, it’s best to try with another partner.

Unfortunately, only experience will allow us to detect this quickly. Otherwise, a toxic relationship will form that won’t end well. But that shouldn’t take away our desire to try again and again until retirement, severance, or the grim reaper finds us.