Pair programming: common problems and solutions

I think of pair programming as a powerful technique that I would never want to miss in my tool belt, no matter what the project is. But similar to any other skill it takes a good amount of practice to master it.

If you just started to experiment with pair programming in your team, there’s a good chance that you’ll face some problems. Don’t get discouraged when it happens. Most of the problems you’ll encounter are actually quite common.

I’ve prepared a list of all the problems me and my peers have come across ourselves. Hopefully, this list can help you on your own journey.

We don’t pair as often as we’d like to

When some teams begin to experiment with pair programming, they might find that the technique is really valuable to them. Everyone on the team enjoys the pair programming sessions. The team decides to do more pair programming going forward. Interestingly enough, some teams abandon the technique at this point. Why is that?

  • The team feels a lot of pressure. When project delivery dates start to slip, there’s a tendency for teams to go into crunch mode: Team members work extra hours, disciplines are abandoned and communication is reduced. Just get the code out, okay?

    What can you do? Remind everyone that the only way to go fast is to go well. Identify the number one priority and bring everyone together to complete it. Once done, repeat this for priority number two etc.

  • The team is working on too many things in parallel. Occasionally, teams find themselves juggling many streams of work. Typically, this is because of unplanned work like security patches, dependency upgrades or bugs being found. To cope with the unplanned work, teams often assign one stream of work to every member.

    What can you do? Limit the amount of work in progress. Identify only one or two streams of work and ask everyone to help complete those first. Placing an artificial constraint on how much can be done in parallel often gives team members the breathing space they need to pair programm.

  • Management doesn’t want the team to pair. I’ve been in teams where managers didn’t like to see people pair programming. How they express their dislike is different. Some bring it up openly, other’s mention it only privately and in 1on1s.

    What can you do? Seek first to understand, then to be understood. Listen to your manager’s concerns. Then see if you can convince them about the value of pair programming. See it as an opportunity for growth. There’s lots to be learned in situations like this.

Our office is not set up for pair programming

If pair programming isn’t that common in your team, department or company, chances are that your office doesn’t really support that style of working yet. I found that many of those obstacles can be overcome with just a little effort.

  • I don’t feel comfortable being so close to my colleagues. This happens easily if both of you are hunched over the same notebook or if you’re looking at a single small display for extended periods of time.

    What can you do? Get a second display, place it at a comfortable distance to the other one and set both to mirror the same content. Now you can look at the same thing while keeping a comfortable distance to each other. Pass keyboard and mouse around or bring your own set. Pick a font size large enough for everybody.

  • I’m not comfortable using the keyboard or mouse of my colleagues: Maybe they use a different keyboard layout or their input devices don’t offer the same ergonomics as yours.

    What can you do? Bring your own set of input devices to a pairing session and attach them to the same computer.

  • Our colleagues think we’re too noisy. When everyone around you is forced to listen to your conversation it can be very distracting for them. This happens especially in open-plan offices.

    What can you do? Find a meeting room or a space in a shared area where other people don’t feel distracted. Alternatively, you could try to do some remote pair programming from home.

Pair programming isn’t really working for us

Not everyone likes pair programming and that’s perfectly okay. Some people prefer to work solo and you should respect that. Others, however, would be keen to try pair programming again, but they encountered obstacles in the past. Some of them can be overcome together.

  • Pair programming is too exhausting. Working so closely with someone else on the same problem can be very intense, especially when it happens for long stretches of time.

    What can you do? Take regular breaks, e.g. every 20 minutes. To not forget them you can use a simple kitchen timer. This approach is known as the Pomodoro Technique.

  • We don’t know enough about the task at hand. A pair of developers occasionally comes across a task that they don’t know enough about. It’s easy to get stuck in a situation like that.

    What can you do? See if you can bring in an expert and create an impromptu mob programming session. If you can’t find someone right now, you might decide to work on something else.

  • My pairing partner is dominating the entire session. I’ve seen this happening when one developer knows a lot more about the tools or the problem at hand. In cases like that they might decide to just take over control and do everything, while the partner turns into an observer.

    What can you do? Establish some artifical constraints to help with yielding control regularly. Techniques like ping pong pairing or strong-style pairing can help.

Our codebase makes it hard to work together

If you find yourself working in a legacy codebase that was neglected for too long, chances are that you spend most of your pair programming session trying to cope with the mess around you. You would run into the same problems working solo, but pair programming makes them easier to spot.

  • We spend a lot of time waiting for our builds. Large and complect codebases have this annoying property of taking a lot of time to build. If every little change requires you to wait for a few minutes, you’ll mostly be waiting in your pair programming session.

    What can you do? Begin by acknowledging that you have a big problem that needs to get fixed. See what you can do to reduce build times. Is there a way to speed them up? Can you isolate the piece of code you’re working on?

  • It’s too hard to understand what this piece of code is doing. When this happens, it might be easier to avoid the piece of code, to not touch it, and work your way around it.

    What can you do? Embrace the fact that you’ve got a partner to look at the same piece of code with you. See if you can refactor the code together so that it is easier to understand. To loosely paraphrase Kent Beck: Try to first make the change easy, then do the easy change.

  • We keep chasing down rabbit holes. If you keep refactoring your code as a pair, it is really easy to get lost in the process. Occasionally, you might find that you haven’t accomplished anything close to what you were planning too.

    What can you do? Take notes as you discover things that need to be improved instead of fixing them immediately. Use your breaks to get back your high-level perspective. See what things you should do now and which ones could wait.