So how good is pair programming, really?

Rickard DahlstromTech Stuff, Web Development8 Comments



This week we’ve got Rick, our longboarding-freediving-Swedish speaking front-end dev talking about the positives and negatives of pair programming. See the summary below for TLDR.

Pair programming (sometimes called peer programming) is a controversial topic. Some developers love it and some grow horns of hate as soon as they hear the words. There are studies that show the great benefits of higher productivity and a safer product. Who ever I ask or whatever articles I read there seems to be a strong opinion either for or against.  I’ve done some research in an attempt to bring some clarity to why it’s so controversial and how and when should it be performed.

Other questions I’d like to answer are…

  • What’s the good and bad?
  • How common is it?
  • Why are not more pair programming?
  • What is the proof?
  • How to measure the value?
  • What are the things you mightn’t have thought of.

What is pair programming?

Pair programming is when two developers are coding together. Meaning one is typing and one is observing. There are different approaches and best practices of how to best co-operate. Most commonly the one who is typing is called the driver. Their main focus is to write and think about the current task. The current task is usually a smaller piece of a bigger task. The person beside is called the Navigator. The Navigator will focus more on detecting bugs and problems, structure and what to focus on next. The idea is to split up responsibility between the driver and navigator to keep a steady development flow, avoiding bugs, better structure and while doing that share more knowledge across the team. The driver and navigator should be constantly talking to keep both involved. Pair programming could be good learning for both.


In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone.

Additionally, 95% of the surveyed programmers stated that they were more confident in their solutions when they pair programmed.

Pairs spend about 15% more time on programs than individuals.

However, the resulting code has about 15% fewer defects.

IBM reported spending about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”. Pair programming significantly reduces these expenses by reducing the defects in the programs

Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early

Benefits, promises and opinions

  • Safer code: Since we have two brains focusing on the code we will reduce errors and failures.
  • Save time: The actual development time might be a bit faster or slower but with a higher quality we will save time in error fixing and refactoring code.
  • More money: Since we know that time is money we will save money too. But also if we can have less errors and other issues we will have happier users. Happy users is often equal to more money.
  • Better code: With a partner you’re able to discuss different structuers and solutions you wouldn’t come up with by your self.
  • Better team knowledge: Pairing means more communication. The side effect is better spread knowledge across the team regarding coding, project, company, work flow and anything else related.
  • Faster learning for Juniors: Juniors often learn much faster when pair programming with a senior. Getting more insights of the code and the company.
  • Better understanding of the task: To have good collaboration it’s important to be clear about the task. By explaining the tasks we often get an better understanding of it. Maybe questions arise and solutions are made before even any code is written.
  • Shared experience across the team: While pair programming you will constantly learn from your partner. Yes, even if you’re senior you have things to learn. It’s also a good time to share your good tips when you’re coding.
  • Confidence: Pair programmers often have a higher degree of confidence since two brains have been part of the development and testing.
  • Happier employees: Some think it’s more fun and are more satisfied with their work environment. It’s also a great time to make friends with the ones you normally don’t hang out with.
  • Higher focus: Since you have to collaborate you’re more likely to focus more. Having a constant dialog also helps you to stay focused.  


The down sides

But, can it really be that good? There must be some down sides as well.

  • Lack of will: Some simply prefer and work better alone.
  • Wrong tasks: Pairing at the wrong time can be both time consuming and inefficient.
  • One can slow down two: If one is a slow thinker/typer or unfocused it can slow down the other one as well.
  • More talk less coding: You might end up explaining things that would be faster to just code.
  • Lack of code ownership: Since two developers are responsible for the code both can feel that the other one is more responsible. If an error occurs there could be a discussion of who should fix it or if it should be done in pair again.
  • Loss of confidence: Some developers find that pairing a lot loses their confidence of coding alone and they want to pair on more things than necessary.


Pair combinations

Senior – Senior

Even though you’re a senior you can make mistakes, won’t always see the best solution and will always have something more to learn. Pair programming could be a good way to fill those gaps.

Senior – Junior

This is a great to speed up the learning curve for the junior. The junior may have a more open mind and question things the the senior just got use to. This could be a great way to increase experience across the team but…

Be careful. Balance is important. If cooperation is not good the junior might end up just watching. The senior could be annoyed by explaining and feel resistance in his/her development flow. Make sure to find a good balance that works for everyone. E.g if the manager/boss is clear about the importance of every ones learning the senior might feel better taking time to explain . The employer invests in a productive team so pair programming could in this case be a good investment for the company. That could make the senior developer more motivated to teach and less frustrated of slowing down his/her coding.

Junior – Junior

This combination could significantly improve productivity and quality. Since juniors have more to learn and more questions they can now learn from each other and develop their skills faster.

When to pair and when not?

Since pair programming will/should increase the concentration for both it may not always be the case. Many tasks may not be suitable for a pair, simple tasks for example. What is a simple task depends of the experience. For a medium hard task either a solo senior could solve it or a pair of juniors. Or maybe it’s touching a core feature so having a senior – junior combination might be a good opportunity to strengthen the junior skills and knowledge.


Experiences of an experienced pair programmer

From my experience there are often very strong opinions about pair programming, love or hate. Statistics may say one thing but some developers mean the opposite. Mark Piper has 5 years experience of pair programming and 2.5 years as a manager of pair programmers. He wrote a great hate/love article and made many good points I’d like to share with you. I recommend you to read the full article but this is a summary.

He talks about an enormous learning curve when he started pair programming**. Not only about the code, but insights about the products, past history, the organisation, and about other technical areas. He talks about the fun of pair programming but also the understanding of other programmers. Class names and structure that makes sense for one might not for someone else. Pairing with experts taught him real insight into Test Driven Development, far more than he could ever have gotten from books or websites.

He talks about the frustrating part of working with someone that’s slower or having to explain things he would prefer to solo code. Working with someone with violently different views on developing software makes it hard to agree on a solution. As a manager he has seen a common feeling of dis-ownership of the code. He also seen developers getting too used to pair programming so they become afraid of doing things alone. Wasting time in e.g waiting for the partner’s meeting to finish. When one person is disruptive or unfocused, it disrupts or unfocuses two people instead of one.

Mark means that courage is the most important factor to make it efficient.

  • Courage to tell your partner you can do the task better alone.
  • Courage to tell your partner to focus.
  • Courage to ask for an explanation you think you “should” know instead of waiting and hope things get clearer.
  • Courage to have an argument that you might just lose
  • Courage to admit that you’re both stuck and need to swap pair partners to bring a fresh pair of eyes to the problem.

Please go ahead and read the full article


Is pair programming for everyone?

We are all different so obviously the result will vary.  Steve Chafer says in an article

I think it works great for some people, and awfully for others. And there’s not much in between. Some people code faster than they think, and pair programming works well for them, because of the obvious “checks and balances” that you have in that situation. Others need to get into “the zone,” to do well, and that usually means zero distractions. made a summary of different articles and books and again found a love/hate situation. Again, pair programming is proven controversial.


How to measure Pair Programming

Of course it’s hard to measure the value. One reason is, there are many things to measure. The other one is, it’s just hard to measure.  Values that is worth to consider could be. 

  • Development time: How much more/less time is spent on development.
  • Fixing time: How much more/less less time is spend on fixing errors or refactoring.
  • Enjoyment: How much more/less work satisfaction do the employees feel?
  • User satisfaction: How much more/less happy clients and end users do you have?
  • Money: If you get this data you should have an idea of the economic value as well.

If you’re not already doing it, catching ALL errors from your software/app/website/etc is a must. If you launch a product without receiving all errors your users experience in real time you will probably lose costumers and money. So first of all, track all your live errors. Yes we at Raygun know the importance and the value of this. That’s why we made Raygun. So sign up today and get invaluable insights about your product. Once you know all about your errors you can easily compare solo-/pair -programming.


After a lot of reading I still find it hard to tell how common pair programming is. On one side we have companies that use it as a well implemented method and have proof of the benefits in terms of less errors, repairs, support and are saving money. On the other side we have companies that would never touch it.

So why are solo programming companies solo programming? Is it because it’s just better for them or is it lack of experience and knowledge, fear of the change, lack of motivation (not being convinced about the benefits) or is it because they didn’t even make a choice?

First of all I think the question is wrong. It’s not about being a solo company or not. It’s not about being a pair programmer or not. Pair programming is just a tool. Like all tools it’s great for some tasks and garbage for others. It’s like asking a design company if they are a Photoshop company or not. Of course they’re using the tool the suits the task best, sometimes illustrator, in-design and sometimes Photoshop. With this point of view I understand even less why so many are for or against pair programming. For me it’s more of matter of using a great tool when it make sense.

I believe that with an open mind all companies can find some use for it. Some very little and some a lot. I also believe that it’s only one way to find out. TRY IT. I don’t think we have anything to lose but a chance to win.

Are we different kind of developers? It seems like it’s not only the task that determines if it’s a good choice to pair program or not but the type of person matters as well. Maybe we are just different, some prefer solo and some pair. In sports it’s well known that some perform better as individuals and some in teams. Some athletes are hybrids and work well in both scenarios.  Why would developers be different? Maybe it’s a matter of understanding ourselves better to know what works best for us. Maybe some companies choose to be solo coding companies because they have more individualists in their companies.

It’s hard to tell if it’s good or bad, when it’s good or bad and for whom it’s good or bad. But again try it to find out. Ask the team about their opinion, test it on a small scale and ask the team again. You might find that some people love it and some hate it. Maybe some like to pair program and some not. Maybe you find small benefits and get encourage to try it on a bigger scale. Maybe you’ve realised that pair programming was just not for your team, but at least you know it now.

From my understanding there’s nothing bad with pair programming itself, it’s just a matter of finding the right combination of developers for the right task. For that experience is required. For experience trial and error is required.

Please leave some comments to let us know your opinion.

If you’ve just stumbled across this page. We have a great webinar on post-agile practices including some references to pair programming. The webinar is available here.

And, this excellent post on “How Exception Monitoring Increases Innovation”


Some of the most interesting articles I read.

– Rick

We would absolutely recommend Raygun to any business which relies on healthy software to serve there customers. Andrew Schofield, Chief technology officer at Timely. Take a free 14 day trial. Request a short demo of Raygun.

8 Comments on “So how good is pair programming, really?”

  1. Karl

    IME Pair programming is great for getting new or inexperienced people up to speed, even in new languages. It’s also great to get instant feedback about design choices and avoid having to do later code review. But I’ve been in an environment where every day all day was pair programming, and it’s super stressful. It amplifies personality clashes and can even stir up conflict that didn’t need to exist, just because of the tight social feedback loops. It can also be a real drag for people who tend to code intuitively to have to explain every decision. And some days you just put on some headphones and not have to deal with people. Full time pair programming also basically abolishes working from home, which totally sucks. What I really want is a team that pairs frequently, but not all the time. I don’t need the “extreme”, I just wish I could get the best of both worlds.

  2. Mike Nelson

    I’d agree with your assessment that it is a tool that can be used and does not need to be always used.

    When developing Speaking Email weve had two people on it almost the entire time, which works very well. When we split off and came back together we often we had less progress than we expected to. There are a lot of moving parts and its new territory for us so pairing in his situation is very valuable.

    In other cases, where you are doing basic stuff, it is less valuable.

    We use Senior-junior pairing for bringing new devs up to speed and this works well but certainly can be frustrating for both people. We also use senior-senior for tricky or strategic features, which helps increase the teams knowledge of the project, technology and techniques. Money-wise though we find senior-senior pairing where 2 brains are not necessary increases cost on the project, and some people don’t enjoy it so much, so we dont do it outside these situations.

    I personally find it more enjoyable (usually) and produces more solid code in any pairing but especially senior-senior pairings. So I try to use it as much as possible, whenever I can rope someone in to help on my project, or I go and help with someone who’s got questions on a project.

  3. Pingback: Happy UI and a New Member - The Raygun Blog

  4. Pingback: Agile Practices - What Comes Next? - The Raygun Blog

  5. Pingback: Techniques for Sharing Sandboxes in Demandware - LYONSCG

  6. Pingback: How to Share Sandbox Environments - LYONSCG

  7. Nd

    Great article, one thing I found missing is evaluating developer performance in the pair programming model ? Can you cover little bit about it.

    1. Freyja Spaven

      Thanks for the suggestion ND – that’s a great idea, we’ll add a few lines about evaluating developer performance and let you know!

Leave a Reply

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