Pair Programming Will Either Save or Ruin Your Day

Photo by Fiona @fionawang on Unsplash

Feedback is only useful if it’s timely.

If you are at the point reviewing a Pull Request and see issues, it’s too late — you might be asking a software engineer to miss a deadline because of an unwritten rule. You might be asking a developer to work extra hours because you don’t like the structure of their code.

We should have a system in place where we help developers by giving timely feedback. The best system I know of for this is pair programming.

This recommendation comes from someone who hates speaking to other programmers. I believe the benefits are just so clear we should be introducing this across the board.

So, what is pair programming, and how can we implement it?

What is it? Peer Programming

In pair programming, one developer of the team takes control of the input on a machine (commonly known as the driver), while one reviews the code as it is typed in (commonly known as the observer).

To keep things fresh, the two developers switch roles frequently.

There’s plenty of evidence about pair programming. In one study pair programming completed their task 40% faster than the individuals (and this result was statistically significant).

Why Pair Program?

Stop the Silliness

When working together with someone else we can see the truism that two heads are better than one. Rubber Ducks? They don’t work well when you just can’t see the solution as they seem quite unable to talk back to you.

Pair programming? You can catch one another’s foggy thinking (the sillier the mistake the better if you have a good relationship) and catch issues.

Photo by Priscilla Du Preez 🇨🇦 @priscilladupreez on Unsplash

Working together helps to form a team bond, which is actually a proper team (if you’re bonded properly). Sharing knowledge throughout the project actually helps destroy the idea of a developer caught in a silo and helps them to grow!

Redundancy

I’ve been in a situation so many times where I’m expected to maintain code and simply don’t remember anything about it. Even though I wrote the code. All I need is a reminder, some clue somewhere that nudges me in the right direction and jogs my memory. It would be great if I have someone to lean on, to discuss the issue with and remind me of the work we did.

When you work together in a pair there is some redundancy. That means someone else in the organization knows what you know, so if one person leave the company all is not lost. 

Working together means making deadlines, pushing quality code to develop organizational knowledge.

The Arguments Against

Two is More than One

There is no way to sugar-coat this, if you have the wrong people, they will use pair programming as an excuse to do less work. Effectively you’ve got two people working on the same problem or ticket, and (looking at my calculator) 2<1.

At my current job we worked 3 of us started work on a problem. Every 40 minutes we took a 15-minute break and (surprise, surprise) it took a long time to solve the problem. 

I would say that any policy can be abused, and we really shouldn’t accept we can’t do something simply because it doesn’t immediately work with the employees we have.

People change over time, and getting the right policy and policy right is more important than the initial implementation.

Photo by Hannah Busing @hannahbusing on Unsplash

Software Engineers Dislike Teamwork

I’m pretty bad at working together. I don’t work in an office; I work 100% from home and turn down any opportunity to collaborate in person.

I know I’m not the only one. I get nervous at the idea that I need to code in front of other people, and when I do so I often make mistakes that I wouldn’t otherwise.

Here is the thing though. When I pair program I write better code. I feel closer to my workmates and most importantly (to me) I feel much better.

Does this apply to everyone? Of course, it doesn’t. In implementing pair programming there has to be flexibility for those who will not or cannot work in a traditional pair programming fashion. For the majority though? Pair programming can help.

Implement a Pair Programming Policy

Creating a pair programming policy can be transformative in software development.

If a firm wishes to implement such a policy here are the main considerations:

Buy-in

Like any process change, getting buy-in from senior developers and stakeholders is essential. 

Guidelines

Create guidelines about how pair programming might work. Is it appropriate for all tickets and all problems? Is asynchronous pair programming acceptable? How will staff be trained?

If data can be collected and a feedback loop developed there are opportunities to understand how beneficial the arrangement can be, and how it might be improved.

Opt-out

Pair programming might not work for everyone. Having an inclusive policy is of course important. Consider diversity and consider how to make the environment as beneficial as possible to creating great software.

Conclusion

Pair programming. I personally love/hate it.

That’s because there is nothing in software engineering that is without cost, that is purely beneficial.

However, I say if you want to improve a pair programming policy will help you, no doubt.