# [The most frequently asked question](/content/articles/pair-programming/index.html)

[Mike Charlton](http://mikekchar.github.com/portfolio/)
21 March 2014

- [Share on Facebook](http://www.facebook.com/sharer/sharer.php?u=http://sharktank.co.uk/articles/pair-programming/ "Share on Facebook")
- [Share on Twitter](https://twitter.com/intent/tweet?url=http://sharktank.co.uk/articles/pair-programming/&text=The%20most%20frequently%20asked%20question "Share on Twitter")
- [Share on Google+](https://plus.google.com/share?url=http://sharktank.co.uk/articles/pair-programming/ "Share on Google+")
- [Share on LinkedIn](http://www.linkedin.com/shareArticle?mini=true&url=http://sharktank.co.uk/articles/pair-programming/ "Share on LinkedIn")

We have been on a bit of a hiring spree recently. As part of the hiring
process I try to make sure the candidates know what they are getting into if
they join our group.

“We do virtually all of our work using TDD and spend 80-90% of our time doing pair
programming. How do you feel about that?”

On hearing this, many candidates shuffle uncomfortably and glance furtively
around the room. “You don’t actually do that, do you? The pair programming
thing, I mean.”

This is probably the question we field the most from candidates in our
interviews. Indeed, we do use pair programming almost all of the time. What’s
more, even though there is a lot of peer pressure to pair, nobody is forced to
do so on our team.

While pair programming has gained some acceptance in the industry lately, it
still isn’t pervasive. Many people have experimented with pair
programming to help solve tricky problems, or to get introduced to a new area
of code, but relatively few people have tried pair programming over a number of
contiguous days. “Isn’t it slow and wasteful?”, they often argue.

Pair programming on a regular basis is a very difficult discipline. It requires
a set of skills that many programmers have not had much experience with. It
also requires a significant amount of practice before one can do it well. Once
proficient at it, though, a good pair can perform both better and faster than
two people working alone.

I think one of the biggest problems that beginning pair programmers have is
that they view the discipline as merely a continuous code review. They refer
to the non-typing party as the “observer” whose role is chiefly to catch
mistakes. If one does pair programming in this fashion, I think it
is understandable to see the observer as being something akin to a
very expensive spell checker. Are they actually doing anything that can’t
be done more cheaply with code reviews?

At the risk of being controversial, I will say that catching errors is not one
of the benefits that I am looking for when pair programming. Don’t get me
wrong, I value the extra set of eyes when pairing, but for me this is the
smallest benefit you get. In fact I see pair programming as a way of
significantly improving the speed that a team can generate code. There are
several areas where this improvement can happen: communication,
separation between coding and planning, and a programmer’s ability to concentrate.

First and foremost, pair programming fosters improved communication. A team
will always have disagreements about design and coding style. When pair
programming, you always have immediate feedback for your ideas. Conflicts are
brought out early rather than left to fester. Importantly, controversial code
doesn’t get a chance to become entrenched in the code base. Because feedback
is immediate, you avoid the situation where you are forced to accept something
simply because it is finished and rewriting it will take too much time.

Our team actually does code reviews _and_ pair programming. A pair has a much
better chance of getting controversial code through a review than a single
person does. Having at least one other person listen to and understand the
reasons for doing something makes it easier to explain to others. This saves a
huge amount of time and enables the team to bring on new techniques that might
otherwise be too controversial to accept otherwise.

One of the things that people ask me once I have asserted that we really,
actually pair program is how to do it effectively. Probably the best way to
learn pair programming is to do [Ping Pong\\
Programming](http://c2.com/cgi/wiki?PairProgrammingPingPongPattern). It is a
simple technique where one person writes a failing test and the next person
makes the test pass. After making the test pass, the second person writes
another failing test and hands the keyboard over. Just keep doing this over
and over again.

As this technique is best suited for development of new features, it works
extremely well when doing katas for practice or fun. In fact, if each person
tries to do the least possible work while simultaneously trying to force the
other to do the most possible work, it makes excellent TDD practice. There are
many places on the internet where you can find good katas. We had a lot of fun
doing the katas on [cyber-dojo](http://www.cyber-dojo.com/), though it appears
to be down as of this writing.

Ping pong is an excellent exercise for ensuring that both parties get equal
access to the keyboard and are engaged in the process. It is not the best
technique for all situations, though. Many times it is better to use a
driver/navigator approach.

I often think about this style of pair programming as being similar to the
driver and navigator in rally car racing. A rally car race is a stage race
where participants drive a long course, usually on normal roads. It is
impossible for the driver to memorize the entire course, so a navigator
accompanies him. The driver’s job is to drive as fast as humanly possible
without crashing. The navigator’s job is to plan ahead and warn the driver of
upcoming corners or difficult areas. Usually the navigator uses some kind of
code to tell the driver which gear he must use, or how fast he can take the
corner. The advantage of having a navigator is that the driver can drive
_much_ faster than they could if they were driving alone. The driver is freed
from thinking about what is coming up and can devote their entire attention to
driving quickly.

In driver/navigator style pair programming, one person, the driver, is in
control of the keyboard. The driver’s job is to write code, while
concentrating on the task at hand. The other person is the navigator and their
job is to plan further ahead, keeping notes for possible upcoming work. Often
the navigator will keep the big picture in their head and plan what needs to be
done. When the driver finishes a section of work the navigator can take over,
having already come up with an idea of how to tackle the problem. This
separation between coding and planning allows the driver to code much faster,
as they can rely on their partner to plan for upcoming potential problems.

Whichever way one does it, one of the main benefits of pair programming is
improved concentration. I imagine that every programmer has experienced “white page
syndrome”. When you have a problem that you must solve, but don’t know where
to start, sometimes it seems too daunting and you just stare at the blank page
wondering what to do. Other times, programming can simply be lonely and
boring. Having someone beside you who can cheer you on is an amazing aid.
When one person is feeling down, or listless, the other person can help them
over the hump.

Many people have heard of the [mental state called\\
flow](http://c2.com/cgi/wiki?MentalStateCalledFlow). Getting into a flow state
and maintaining it is essential for a high pace of development. Lately, however,
there have been a few blog posts about the [potential downsides of encouraging\\
flow.](http://blogs.msdn.com/b/eric_brechner/archive/2013/12/01/the-flow-fallacy.aspx)
One of the great strengths of pair programming is that the navigator is often
not in the state of flow. In fact, the navigator is often interruptible and
can respond to outside demands while the driver carries on with the current
task uninterrupted.

I often tell people that good pair programming is incredibly taxing. It’s
actually important to remember to take breaks. Often I find that I will go an
entire morning without looking at my email or doing anything other than
concentrating on programming. Several of us use the [Pomodoro\\
Technique](http://en.wikipedia.org/wiki/Pomodoro_Technique) to ensure that we
take a break at regular times. Even so, I am grateful for XP’s [Sustainable\\
Pace](http://www.sustainablepace.net/what-is-sustainable-pace), because by the
end of the day, I’m finished and not fit for programming any more.

As I said earlier, good pair programming is very difficult. I find that it can
take up to 6 months for a team to learn to do it well. Even then, it is quite
easy to find ways to improve your skills dramatically after that. If you would
like to learn pair programming, the most important thing is to stick with it
and practice. [Coding Dojos](/content/articles/what-is-a-coding-dojo/index.html) are a great way to
meet experienced people who can show you pair programming. There are coding
dojos in many countries and it is worth seeking them out. Even if you can’t do
pair programming on a regular basis in your day job, setting up a coding dojo
for practice can help you develop your pair programming skills.

[See all articles](/content/articles/index.html)

Disqus Comments

We were unable to load Disqus. If you are a moderator please see our [troubleshooting guide](https://docs.disqus.com/help/83/).

G

Start the discussion…

Comment

###### Log in with

###### or sign up with Disqus  or pick a name

### Disqus is a discussion network

- Don't be a jerk or do anything illegal. Everything is easier that way.

[Read full terms and conditions](https://docs.disqus.com/kb/terms-and-policies/)

This comment platform is hosted by Disqus, Inc. I authorize Disqus and its affiliates to:

- Use, sell, and share my information to enable me to use its comment services and for marketing purposes, including cross-context behavioral advertising, as described in our [Terms of Service](https://help.disqus.com/customer/portal/articles/466260-terms-of-service) and [Privacy Policy](https://disqus.com/privacy-policy), including supplementing that information with other data about me, such as my browsing and location data.
- Contact me or enable others to contact me by email with offers for goods or services
- Process any sensitive personal information that I submit in a comment. See our [Privacy Policy](https://disqus.com/privacy-policy) for more information

Acknowledge I am 18 or older

I'd rather post as a guest

- [Favorite this discussion](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default# "Favorite this discussion")

- ## Discussion Favorited!

Favoriting means this is a discussion worth sharing. It gets shared to your followers' Disqus feeds, and gives the creator kudos!

[Find More Discussions](https://disqus.com/home/?utm_source=disqus_embed&utm_content=recommend_btn)

[Share](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default#)

- Tweet this discussion
  - Share this discussion on Facebook
  - Share this discussion via email
  - Copy link to discussion

- [Best](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default#)
  - [Newest](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default#)
  - [Oldest](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default#)

Be the first to comment.

[Load more comments](https://disqus.com/embed/comments/?base=default&f=sharktanklabs&t_u=https%3A%2F%2Fsharktank.co.uk%2Farticles%2Fpair-programming%2F&t_d=The%20most%20frequently%20asked%20question&t_t=The%20most%20frequently%20asked%20question&s_o=default#)

live.rezync.com

# live.rezync.com is blocked

This page has been blocked by an extension

- Try disabling your extensions.

ERR\_BLOCKED\_BY\_CLIENT

Reload

This page has been blocked by an extension

pippio.com

# pippio.com is blocked

This page has been blocked by an extension

- Try disabling your extensions.

ERR\_BLOCKED\_BY\_CLIENT

Reload

This page has been blocked by an extension