Breaking down successful pair programming

Dilbert comic about pair programming

Explorations into successful pair programming characteristics broken down by common pairing scenarios.

Pair programming was brought into the mainstream by the Extreme Programming movement and is steadily gaining popularity in production environments. In my two years of pair programming and leading other pairs, I’ve noticed that sometimes pair programming is fantastic and once, can be even magical. And sometimes, it really sucked. I wanted to explore the reasons behind this and have identified a few patterns that might shed some insight into what it takes for pair programming to work well.

My pairing experience

I believe its important for you to know what kind of experience I have so you can evaluate this post within better context. I’ve been pair programming almost every day for about two years with two different companies. One was a consulting company where we developed applications for clients. The other was a high growth startup developing a large SaaS product. Through out this time, I paired with over 20 developers all with different backgrounds, personalities, skill, experience and cultures.

Side note: Just realizing how much of a benefit that is when you pair program. I’ve met so many wonderful people and have become friends with many of them.

Is pair programming worth it?

I wrote a bunch of stuff here on this topic in my draft but deleted it because I don’t want to confuse the point of this post. There are many other research papers, opinions, stats, that say one thing or another. I don’t think this question matters much in a general context. There are far too many variables.

In the writing below, you will see that I do believe there is good and bad pair programming. So my answer to this question is the most popular answer in our industry – “It depends.” :)

And while I may have your attention on this topic, I will mention that I’ve noticed that pair programming will help the business if it also helps the programmers. (This may deserve a future post.)

Characteristics of effective pairs

When I think about all of my good and bad pairing experiences, many things that go through my head. Instead of repeating all of that, I summed everything up into this fancy, MBA, consulting style two-by-two matrix.

Pair programming success matrix

Pair programming success matrix


(Mind the) effectiveness gap

In my observations, the most relevant, distinguishing factor between pairs was the gap in effectiveness between the two individuals. Many things go into how effective a programmer might be – their previous experience, domain knowledge, language knowledge, etc. If we combine all of those things together, we’ll get “effectiveness”. Perhaps another way to think about “effectiveness” is the potential strength of their output, including speed and quality. For the purposes of this discussion, I’m going to refer to high and low effective programmers as “seniors” and “juniors”.


When pairing, the hope is that the business (and the individuals) will benefit more than if the two worked independently.

Pairs with small effectiveness gaps

In my experience, these generally worked out better than pairs with large gaps. Perhaps the reason is because the developers have more in common, which equates to instant “free” empathy which helps improve their interactions. I believe the points outlined in the matrix are clear. Essentially, strong pairs with small effectiveness gaps have a good chemistry. They understand and respect each other, communicate often, and help each other learn. It results in a very satisfying and mutually beneficial interaction. It’s usually a lot of fun too.

If we dig a level deeper, there are different characteristics between senior and junior pairs.

Junior pairs

It is my observation that junior pairs provide more benefit than senior pairs. Why? Probably because junior developers have weak opinions, their egos are smaller, and they care more about learning as opposed to being “right”.

I also believe there’s the “new kids in school” effect happening. Imagine you’re a kid and your family moves to a new town in the middle of the school year. If there was another kid in your class who also joined around the same time as you, you’d probably become friends rather easily since you’re both in the same situation. It’s the same with pairing. If you’re both new to the app/technology/language/whatever, you’ll instantly have more empathy for one another. You’ll want to explore similar things, get excited about solving the same type of problems and generally collaborate well.

When two juniors pair, the primary goal should be to learn.

Senior pairs

When both developers are seniors, it’s harder to get a good match for the same reasons. Every programmer is different, and has different opinions. The more experience you have, the stronger those opinions are. Also, when you know a lot, it is possible for it inflate your ego. When one person has a large ego, the pair may yield poor decisions due to being insecure or the there person “tiptoeing” around to ensure they don’t dent their pair’s ego.

Even worse is when both pairs have large egos. In this case they argue (not debate) a lot and it can become tense with animosity. The worse I’ve seen is when the navigator would physically walk away from the workstation for extended periods of time. The pair wasn’t even communicating at this point and obviously in negative benefit territory.

Good senior pairs have a lot of respect for each other. They talk a lot. They debate, discuss and plan. They work at a professional level, not personal. It is a thing of beauty. And the business benefits greatly with strong output.

When two seniors pair, the primary goal should be to produce.

Pairing juniors with seniors

Putting together a senior and junior requires a different approach. This pairing arrangement tends to happen when new developers join the company or switch into a new development context. The new, “junior” might be paired with a “senior” with the expectation for the junior to ramp up quickly. If the senior is not the right person, or has the wrong expectations, this will turn out badly. and risk hurting the junior’s morale.


Leadership must understand this arrangement is about ramping up the junior as fast as possible. But that must be understood by everyone who has a stake in this pair – the other developers, designers, QA, etc., and, especially the senior. The pair should not have any pressure to deliver, because once they do, it will ruin the pairing dynamic. It will turn into frustration on both sides because the senior will be slowed down by, or will run ahead of the junior.

Output will be slow while mentoring takes place.


Once the senior understands that their role is to mentor, and not to pump out stories, only then can the pair start to engage in beneficial work. But there’s more to consider.

Good mentors listen, answer questions, observe and ask leading questions.

This is really hard to do because as human beings, we tend to do the opposite. So here’s a reminder:

Do NOT tell them what to type, or tell them what to do or take over and show them. Stop yourself. Let them make the mistake you see coming. Let them feel some of the consequences. Let them think about why that was bad. Let them correct it. Let them ask you questions along the way. Try to answer with questions. If they get stuck, lead them out with questions.

I remember I was really under the gun to get stuff done while I was pairing with a brand new co-op student. I knowingly steamrolled my pair and continuously apologizing, which probably didn’t make him feel any better. Looking back, I should have changed the pairing arrangement or found a way to take the pressure off.

It takes a ton of patience, self-confidence and empathy to be a good mentor. We want build the junior up, not show them what you know. From what I’ve seen, good programming mentors are lacking in our industry. Everyone is too busy trying to get stuff done or they just don’t have the human skills to do it well. Some questions that may help determine if someone is a good mentor are:

Do they share knowledge and help juniors often? Do they get defensive about their skills or opinions? Are they comfortable with sacrificing for the good of the team?

When pairing a senior and junior together, the primary goal should be mentoring and learning.

Leadership’s role


In any situation, good things happen when there is understanding between people. Pair programming is no different. Understanding comes from empathy, communication and self-confidence. Business and technical leaders can set the example so it can propagate down through the rest of the team. Culture comes from the top. And it’s not what they say it is, it’s how they act that defines culture.


As I’ve identified above, each pairing scenario is different. It’s important to recognize them as different, understand what will make it beneficial, and communicate that to everyone who needs to know so that expectations are clear and in alignment with the pairing dynamic.


This particular subject reinforced for me that programming is as much about people as it is about technology. We are people, writing software for people, in collaboration with other people. The technical skills are obviously required, but being a great programmer goes hand in hand with being a great person.

Happy exploring!

15 thoughts on “Breaking down successful pair programming”

  1. What a thorough analysis, nice job.

    I’ve always found pair programming to be the most contentious, most hotly debated agile practice. Years ago I wrote an article called Pair Programming is Kryptonite because it seems that many superhero programmers are greatly threatened by it.

    Also, I recently published an interview about pair programming that your readers may be interested in.

  2. Good reading :) And for others watching, I was VP Engineering at Xtreme Labs where Sundeep worked.

    I think we tried really hard to never have junior-junior pairs, since we didn’t find that they led to the mentoring model we wanted.

    I also do believe junior-senior pairing should be focused on delivery (v.s. just mentorship), but that’s my opinion.

    I like the idea of this post, which is to try to distill things down to their core components (why is pairing successful, what can make pairing more effective).

    When asked about pairing and statistics around it’s success, I always used to say: “Pair programming can work in practice, I’m just not sure it works in theory”

    1. Thanks for the comments Farhan :). I don’t disagree with focusing on delivery in senior/junior pair. But when there is continuous pressure, I’ve found it hurts the pairing. If the business/project has a long time horizon, I believe the senior/junior pair will deliver more when the primary goal is mentoring.

  3. I have once done pair programming but that is on an interview, it was good experience but never done something on real project. Though involving team member on something is always remains part of work.

  4. I have been involved in pair programming since college and sometimes it would seem frustrating. Sometime later, when some of us formed a team and started taking part in programming contests, it became pretty clear that pair programming was the way to go. It would create so many ideas and though processes which one of us individually would have struggled with. However, as you pointed out it is important to have a good pairing. I was unaware that this was being used in the corporate world as well, since I have never been exposed to it in work. However, really interesting and thought provoking article.

    1. Thanks for your comment Rahul. You make a good point in your observations that pairing is great for exploring problems which are complex, have a lot of uncertainty, or require creativeness.

  5. Sorry for not giving out the real name, I’ve got my reasons. What’s your thought about a junior-senior pair where the junior knows the technology better but the senior has more domain knowledge? Is it an effective pair? Can steps be taken to make it an effective pair?

    1. Thanks for the question, whoever you are :). Certainly, a domain expert and technology expert can make a great pair. I remember pairing with someone and we started out by identifying where we each were strong and weak. Our thinking was that we wanted to ramp each other up in our weak areas so that later, we could go faster and share the knowledge with other or new team members. So, our pairing dynamic would change depending on the work we were doing at the time. I was sometimes mentoring, or being mentored. It worked well because we were both on the same page about our goals and approach.

      In that long-winded answer, there are some steps: Learn about and understand each other, figure out your goals, and identify how and when to change your pairing style based on the work you’re doing.

  6. Great article :). I found it really useful. Thanks!
    I’m at my 4th semester as a computer science student in Denmark, and we have been using pair programming only this semester. It’s has been a lot of fun and it’s a big success in my group. There are a lot of benefits just like you mentioned: Better code quality, knowledge sharing, more social stuff etc.

    1. Thanks for your comment Thomas. Glad you’re enjoying and reaping some benefits of pairing at school :)

  7. It’s a fantastic article. I agree with everything you mentioned. Having good ‘human’, social skills is obligatory to be good mentor and peer. It maybe even more important than knowledge of technology. This knowledge you can obtain during work, ‘human’ skills are much more harder to learn.

    1. Thanks for your comment Thyliamris. I agree, I think the human side is more difficult to develop because it’s unnatural. I also believe that the payoffs are worth it, so I keep trying to develop myself personally. Which helps in all areas of life, not just programming.

Leave a Reply

Your email address will not be published. Required fields are marked *