In part 1 of my series, I gave an introduction to pair programming and discussed setting up an environment conducive to pair programming. I’ll now talk about the benefits of pair programming.
Benefits
No single point of failure
As I said, there are many benefits to pair programming. For starters, because two developers are actively working on solving a problem or writing a feature, both devs will have the knowledge of the work in their heads. This results in redundancy on the team. There is no “The Guy” on the team who, should they get hit by a bus, go on vacation, or decide to quit, would end up screwing the team over (whether intentionally or unintentionally). There is no single point of failure.
Collaboration and improved design
When two brains are working on writing software, both are giving input and critique to the design of the software being written. Pairing is a great vessel for collaboration. With pairing, you get multiple perspectives of a problem.
Pairing is also great for experimentation. One person in the pair can propose an experimental idea to try and the other can critique and improve it. If there are feelings that the pair is going too far down a rabbit hole, the experiment can be aborted.
Mentoring
I have had the extreme pleasure of working with awesome, intelligent people who have mentored me over the past few years. In my experience, the best way to learn is by doing. When I started my first job, my pair would explain something new to me then let me try doing the work myself, offering me help if I needed it. I think this is a great way to have the struggle that leads to growth while having help nearby if it’s truly needed. When a junior and senior developer pair, it’s usually very beneficial for the junior. It can be a little stressful for the senior since they have to keep on task while making sure the junior doesn’t stray too far off.
I find pairing is most optimal for both people in the pair when they 1) have a similar skill level or 2) have a similar level of familiarity with the codebase.
At my first job, I was not only new to the codebase, but new to professional software development altogether. All of the other devs on the team had experience and had worked in the codebase for some time. When I paired, the other dev usually knew right where to go to do work for a given problem. I just went along because it would have slowed us down if I had taken the time to muck through the codebase to find what we needed to change.
About six months into it, another developer joined our team. He had a few more years of experience than I, but he was unfamiliar with the codebase. Since we both had a degree of unfamiliarity, we were able to explore the codebase together. There was no person with all of the answers right there solving the problem for us. This was great because we were able to explore the codebase and grow together.
Being kept on track
Having another human being present is great for keeping yourself on track. Because someone else is right there, you feel guilty for goofing off on Reddit or Hacker News, so you’re kept on task.
I also mean this in a benign way. Having a pair present is great for preventing rabbit-holes that are normally traversed when a developer is working by themself. Your pair is there to catch you when you fall. Stupid things like syntax errors are quickly found and resolved with another set of eyes on the code being written.
Growth and challenge
I can say that I’m always challenged when pairing with someone (unless we’re stuck doing a menial or tedious task). I might have to explain work that was done on a task to a newcomer. It might be the other way around; I might have to get myself up to speed on work that I was not involved in.
I have to be way more into it mentally than if I were by myself because I don’t want to let my pair down. Hands down, this has made me a better software developer. When pairing, I’m constantly pushed and I’m cool with that.
Gelling
I consider many of the people I have paired with over the years good friends. As you work together with the people you pair with, you get to know them really well and gel. I feel that a team works much better if they get along really well and trust each other.
Part 3
In part 3 I discuss the challenges of pair programming.