Let me be honest with you, pair programming wasn’t really my thing back in the day. I actually pretty much hated it: It seemed intrusive, slow, and even time-wasting sometimes. And It really annoyed me to have someone looking over my shoulder, and seeing everything I typed into my machine.
It’s been two years since then and I’ve spent countless hours pair programming (specially remotely). And I can very confidently say that it’s been one of the most enriching experiences of my career.
Programming with another person can be a pretty intrusive experience when you’re just starting. But it can also be incredibly rewarding once you get used to doing it: You gain access to an entirely new lense through which to see your own code. One that isn’t blind to all your biases and bad practices, and (in the best case scenario) actively challenges you to improve.
Letting another person into your workflow can also lead you to discover parts of yourself (as a professional) that you didn’t know were in you: Maybe you’re a passionate teacher that never had any students before, for example.
And, out of all the things you’ll learn by pair programming, I can guarantee you one: Having a second set of eyes help you code will, without a doubt, teach you a thing or two about yourself and the coding world in general.
Got you interested? Let’s talk about that.
What is pair programming?
Simply put, pair programming is the practice of having two people work on a particular software related problem by sitting together [typically] in front of the same machine. Because we’re attempting to solve a specific problem on a specific piece of code; these people often take different roles in the process:
- Driver: Also known as “the one who’s coding”. She’s mainly concerned with implementing whatever feature the pair was asked to do.
- Navigator: She acts in more of a support role. She spell checks, researches and tests the code in many non-direct ways. Which include: suggesting different syntax, proposing new approaches, and delivering constructive cristicism.
It is often considered best practice to have both people switch roles every session. After all, it’s not as engaging if the same person always gets to drive.
Additionally, even though I mentioned pair programming as being “sitting together [typically] in front of the same machine”, it can actually work pretty well when you do so remotely.
Sites like aptly named Remote Pair Programming are completely dedicated to the topic and offer best practices, tools and a lot of valuable advice on the topic.
The Pitfalls of Pair Programming.
We said a lot of good stuff about pair programming already. And there will be more, lots more. But I feel that it’s also important we discuss the two main problems you can expect to encounter while implementing it:
- Disengagement: This is what happens when one, or both, members of the pair stop contributing to the activity in a meaningful way.
- Navigator: failing to pay attention to the driver or getting distracted.
- Driver: Choosing to ignore the navigator’s suggestions and [ideally] constructive criticism.
- Watching The Master: One of the member’s of the pair feels intimidated by the other, or simply not up to pair with her partner in some way. Because of this, she chooses to neglect driving and, instead, opts to just watch the other programmer as they code.
We refer to these as pitfalls because they result in a lack of participation and collaboration from the pair. And simply put, if both people are not working together, they’re not really pair programming, they’re just watching somebody code.
The main idea here is to remember that pair programming is meant to be a social activity, and for that very same reason it needs the active participation of both members of the pair.
The benefits of Remote Pair Programming:
Let me assure you, all the benefits listed here do not just apply to remote pair programming. But as I mentioned earlier, almost all my experience comes from performing this activity remotely, so that is what I can vouch for.
With that explained, I would like to start with a few more general benefits, before we dive into the very personal one:
- Having two developers working on the same piece of code increases its overall quality.
- At the same time, this also means the pairing session basically comes with a free code review. Although both are equally useful.
- When maintenance is needed, more people know the actual code.
- Code done in pairs usually leads to less bugs, less rework and less backtracking.
- Both developers get to share skills, preferences, approaches and techniques with each other.
- Developers also learn more than a few soft skills indirectly – How to give and receive criticism, for example.
And to these ones, I’d like to add anothe benefit. One that I believe doesn’t really get enough attention when discussing this topic:
Pair programming as team building.
When you’re working with a new team, it can sometimes be daunting to think of ways in which you can engage with them. Maybe you want to get to know someone in particular but are not sure of how to approach them. This is specially true in remote working environments.
It is at this point that remote pairing as a team building mechanism really shines, because it gives all members of the team an opportunity to not only interact, but to also learn to respect each other as professionals by watching each other work.
And working alongside someone for extended periods of time will inevitably lead you to better understand that person, even if just as a professional. You’ll get to know their quirks and style; even their preferred approaches. You’ll be able to notice who wrote a piece of code at first glance.
Curiously enough, these factors (respect and understanding) tend to be at the base of every successful friendship I’ve ever been a part of.
What Developers get out of Pair Programming.
It can be difficult to get started with pair programming. Ego, personal space, a preference for working on your own, and many other factors can result in a more than rocky beginning to this practice.
But as you grow more and more accustomed to working with others, you start to notice the benefits. And (with some luck) you may even find yourself to be a better developer than before you tried it.