So as a developer, which scenario seems more inviting to you.

  1. Sitting in a quiet room, with headphones on, writing and debugging code?
  2. Root canal without anesthesia.
  3. Having someone watch my every key stroke and commenting on the code as I’m writing it?

Most of us would put them in exactly that order. I’m here, however, to tell you that some of your best code and best work is done not when you’re “in the zone” but when you’re paired with someone else, helping to write and review, together, so happy together.

The idea of this hit me a couple of weeks ago… Imagine sitting at a wedding, and hearing a talented and beautiful cello player playing together with a handsome and equally talented pianist (parental bias alert) playing a version of Happy Together by the Turtles. I started thinking that each one sounds individually brilliant, but when working together, the results were amplified and they played off of each other’s strengths and shielded each other’s weaknesses. And then it hit me, programming (like music) is both an art and a science. There are techniques and intricacies that are brought together with opinions and interpretations to produce something greater than each individual could bring alone. For the pair to get there though, they each needed to be comfortable with their strengths and weaknesses and be open to suggestions, encouragement, criticism, and feedback from each other. What the attendees at the wedding didn’t see was the raw process that allowed the beautiful music to come to life. The practices were at times brutal, and stretched everyone’s patience. There were conflicts over interpretations, dynamics, style, structure, and everything else. Sound like fun? What they both (eventually) realized was, that by working together they were able to create something better and more beautiful than either could alone.

Ok, maybe that’s a stretch for a pair programming analogy, but I think it is relevant. As developers, we all know we can create beautiful code that is effective and efficient, and, well … beautiful. But when you work with someone else, and open yourself up to questions, learning, and the feedback that can help shape what you are doing, you will find that you can create much more elegant solutions, much more efficiently, and with fewer errors.

What is pair programming?

Pair programming is an agile programming technique that requires two developers to work on code together, side by side, sharing a screen and keyboard. Each developer has a unique role. There is one person on the keyboard and mouse at a time. Their job as the driver is to type the code. The second person, or observer is responsible for reviewing the written code.[1]

That seems simple enough, but the concept is much more involved. One critical piece of pair programming is the communication that happens during the process. The driver has the responsibility to “think out loud” and ask questions if they are unsure. This requires a bit of openness, and willing to have your ideas critiqued. The driver should talk through each piece they are writing, and explain the structure, intent, and nuances of the code. The observer has an equally important communication role. They need to understand what the driver is doing. This requires them to ask lots of questions, and have things explained they don’t understand. The observer also has the responsibility to think big. They should consider the consequences of the code, and how it fits into the overall architecture. The communication piece of this equation is key. As developers are required to fully think through their code, and explain it to someone else, they naturally approach it differently. It prevents short cuts and mistakes that can occur with quickly written code and hastily executed commands. In a sense, it’s permission to slow down and do it right once.

Why should I pair program?

First, you get to learn. As developers, we should always be intellectually curious and finding new rocks to turn over, and better ways to solve problems, and new technologies that make the world (and most importantly our jobs) easier. You can learn from the most experienced guru as well as the most rookie newbie. The guru knows the traps of software past, and can help you not re-invent the wheel to solve a problem. The newbie has an un-warped curiosity, and if something isn’t obvious to them when you explain it, then maybe it’s not so obvious - time to think it over again. In either case, you bring in diverse areas of experience that might know how a similar problem is solved elsewhere, and maybe you can reuse a method that is already written. (DRY principles anyone?)

Second, you create less errors. By having a second set of eyes on the software you are writing, you make less errors. The second person can catch mistakes you might make as you type. They can also look at the system implementation, and can think about how this code impacts the bigger design. Speaking for myself, I sometimes get lost in the details of the immediate challenge, and forget the bigger consequences of a decision. That’s where some of the most expensive to fix bugs come into place. Not the simple type, but the context changing paradigm misalignments that impact the overall design of the feature you are working on. A subtle side effect of having someone look over your shoulder, however, is that you also tend to think through your code more fully. No one wants to have someone else find a mistake. When you pair, the driver tends to proceed more slowly and more cautiously. Bugs are avoided just because we slow down and think it through.

Third, you gain a shared understanding of the code. One of the mistakes a developer can make is to think of a part of code as her or his code. The best code is clearly written, easily understood, and can be picked up by anyone else on the team to extend, repair, or improve. By pairing with someone on a part of the system where you have little knowledge, you become conversant in how that part works, and can help write parts of it yourself in the future. The best opportunities arise, when as developers we make ourselves expendable. That is a loaded statement, so let me unpack it a little. If, as a developer, you are the only one who knows a key part of the code, or how to operate a key part of the system, you are less likely to be asked to branch out to other tasks and get different responsibilities. This might seem counter-intuitive, but if you are seen as someone who writes effective, bug-free, maintainable code that others can pick up and run with you are more likely to be asked to delve into a new initiative for two reasons. First, you aren’t absolutely required to work on the parts you already created, and second, you have a track record of doing things right. In pairing, you accomplish this mission. You share your knowledge of the code with a team mate so that you aren’t the sole source of knowledge.

Should I always do it?

Pairing isn’t the solution to every development exercise.

I find, for example, that prototyping works best alone. The trick here is to remember that a prototype is by definition throw-away code. You can reference it as you write a new feature, but it’s basically a time for you to try and learn how things work. It’s a chance to research how the system works and read about best practices in the industry, in a safe, non-judgmental environment.

You may also find that there are personalities that you can pair with and some you can’t. I personally like it when I have a very picky observer reviewing the code that I write. I would rather fix any issues up front than have a customer find them. Some people may be pretty blunt and abrasive in their response to things. If you can’t find an effective way of working together, then maybe it’s not the right solution.

How to do it in person?

One of the most critical parts of pair programming is the environment. If two people are literally sitting side by side, then you need a screen they can both see or two screens that are replicas of each other. It doesn’t work if someone can’t see all of what someone else is working on. One thing to remember is that sometimes two screens are absolutely needed because of vision issues. If two people need to have the monitor at different focal points, pairing can literally cause a headache. Experiment with what works for you.

The other critical piece is the noise, or lack thereof. Pair programming requires the ability to communicate between the two partners. They need to be able to do so openly, without worrying about disturbing others around them. How you accomplish this will be in large part impacted by your work environment. Some organizations have dedicated paring rooms, with just a large monitor and a keyboard. Others book conference rooms for the pair work as needed. In some open environments, two people will sit side by side and use headsets to allow them to communicate quietly. This is where you can experiment and find out what works best for you and your team.

How to do it remotely?

The tools available to doing pairing remotely have greatly improved in the recent years. As with in person pairing, the two most important things are both looking at the same screen and having easy voice communication.

For screen sharing, Google(TM) Hangouts is an easy solution, but sometimes the screen resolution isn’t enough to be effective. Other tools have been the use of VNC and Citrix that allow for much more high fidelity screen sharing, and even shared keyboard and mouse functionality. The key here is to not be looking at separate screens with the same code rendered locally. It’s critical that both parties are looking at the same screen so that the driver can use the mouse and cursor to discuss what she or he is doing.

Voice conferencing can be done in a variety of ways. The best results are usually with a headset, so that echo and outside noise is reduced. The challenge here is to find a service that minimizes latency. Remote pairing can be difficult if there is a second or more of latency between when one person speaks and the other person hears. Google(TM) Hangouts work ok, but can have variable latency depending on the network gods. Some teams have implemented gaming voice servers to reduce latency and provide excellent interactions.


Pairing is an opportunity to improve your knowledge of the code and produce better code for your team. You need to be open to feedback and correction while it’s going on, but when you end up delivering code that you feel better about and has less issues we all win. The challenge here is to take a shot at it - find a friend and try it. Give yourself an hour to work on one specific task. Set up the environment in advance so that the first 30 minutes are getting things set up, then give it a whirl. Remember, only the driver types, and the observer should stay focused on what’s on the screen. If you need to look up other parts of the code, have the driver put them up. One screen, one keyboard, one focus. Give yourself permission to slow down and do it right the first time.

[1] -