To Pair, Or Not To Pair?
That seems to be the question…
What Is Pair Programming?
Pair programming (aka peer programming) is when you have two people (preferably programmers!) working together on the same programming task.
“Say ‘programming’ one more time…”
It can be a topic of controversy, causing some to immediately jump to its defense, while others scoff at even the thought. The truth is, you’re going to hear a different answer almost every time you ask the question “Is pair programming really worth it?”. There are many studies that show evidence of more ‘resilient’ code, as well as higher productivity while pair programming, but those haven’t stopped the debate. This article is meant to shed some light on the topic so that you can decide whether or not it’s right for you and your team!
The first argument you’ll usually hear in favor of pair programming is something along the lines of ‘two minds are better than one’, and it’s true! Even if the second mind isn’t necessarily as well-versed as the first mind, the second mind is still adding brainpower. One person may have picked up a small little trick that the other hasn’t, or maybe they’re seeing a future error/problem that the other hasn’t seen yet. How many times have you sat and stared at your screen, not knowing what to do next, wishing there was a little voice in your head telling you the next step? Regardless of the scenario, two minds will always have more brainpower than one.
This also leads to the sharing of knowledge and best practices, which serves to improve the skill of both programmers, and therefore the team as a whole. If you’re working with a large team, the more people that know how the code works, the better! Not to mention the work environment and morale that can be greatly improved due to your team’s growing interpersonal relationships and communication.
There’s also the ‘bus factor’. What would happen to the project if someone on the team got hit by a bus (or more likely needed to leave due to an emergency)? Is there valuable tech knowledge that you’ve now lost? With pair programming, you’re ensuring that multiple members of your team are aware of how the code works, and what it’s doing. This is what is meant by ‘resilient’ coding. Take it from someone who actually has been hit by a vehicle - life can happen anywhere at any time, and the more people you have that know your code, the more protected you are going forward.
What Doesn’t Work?
Alternatively, the first argument that you’ll usually hear in opposition to pair programming is that it’s too expensive. Expensive here doesn’t mean in terms of processing power or time, but rather money! As a business owner trying to make money, why would I assign two people to a job that I believe only requires one? Well hopefully the section above can answer that, but if you’re really looking for some dirt on pair programming, look no further.
Unfortunately, pair programming isn’t really sustainable past 3–4 hours. If experience levels are quite different, individual confidence can start to wane as people think to themselves ‘I don’t wanna seem stupid for even suggesting this, they know way more than me!’. On top of that, people’s attentions start to get drawn away from the project, or one person starts doing most of the work while the other watches. There are times when pair programming can make things harder, and even drive a wedge between two people, so being aware of how much time you expect to work on a given task, or how close a given pair is in terms of skill level should inform your decision on whether or not it is a good route to take. The truth is, everybody works at their own pace, and the pressure of having someone else watching you code can be a bit much for some.
Do’s & Don’ts
If you decide pair programming is the right choice, refer to some of the basic rules defined below:
-DO use the 5-second rule. If your partner has made an error, wait 5 seconds before saying anything, they may notice the error already, so immediately pointing it out can serve to frustrate some people.
-DO switch on a regular basis. That means one person ‘drives’ while the other ‘navigates’ (one writes code while the other reviews the code being written and gives ideas on how to implement new code).
-DO be considerate about accessibility needs. Your partner may need a bit of extra time to think or process things due to accessibility reasons, so be conscious and accepting of your partners’ needs.
-DON’T micro-manage! Telling your partner “Do X here, write Y there” is not the point of pair programming, but rather to communicate ideas and come up with the best and most efficient coding solution as a team.
-DON’T get impatient! It can be frustrating to not be the one in control or to watch someone make a lot of errors that you’re sure you wouldn’t have made. But don’t take that out on your partner! You may instead communicate that you would like to be the ‘driver’ for a while.
Pair programming isn’t for everyone. In fact, some people will argue that it shouldn’t be for anyone, but that just isn’t true. Personally, I can’t recommend pair programming enough, especially to new developers. It gives you an opportunity to see how other people in your team think about and write code, it’s a fantastic way to grow your communication skills and iron out the workflow with your peers, and it serves as an opportunity to test and solidify your current knowledge while gaining new knowledge and insights into things you may not have been totally clear on before.
If you’d like to do some further reading on this very expansive topic, I’ve included some helpful links below! Thanks for taking the time to read!