[ Content | View menu ]

Paired Programming’s Benefits

Mark Mzyk | September 3, 2008

I’ve often read about paired programming, having heard its benefits extolled from Bob Martin when he gave my coworkers and I training, to reading about it at Hashrocket, where they “pair all the fucking time“.

It’s easy to find naysayers and it’s easy to rationalize why it might not work, the biggest reason being that it slows you down.

Guess what?  It does slow you down.

That isn’t a bad thing.

Recently I sat down and paired with a coworker of mine, as we worked to polish a project that is coming to a close.  The experience convinced me that I should pair more often than I currently do.

Why was it helpful?

It kept me focused and on task.  I had someone looking over my shoulder, so I couldn’t let my mind wander and wonder what the blogs were saying today, just because I reached a small breaking point.  What is normally a disjointed coding process for me became a smooth, continuous experience.

Having another set of eyes catches a lot.  Typos and mistakes in logic that normally aren’t discovered until the testing phase get caught immediately, because while one person types the other is checking behind them, in a way that only a human currently can.

Pairing forces you to address problems sooner.  Someone else now knows about that small flaw you introduced, so there is outside accountability.  The longer you leave the mistake, the worse you look.

Pairing uncovers mistakes that normally aren’t caught until the eleventh hour.  How often have you had a logic bug in some code that makes complete sense to you every time you look at it, but once another person sees it, they remind you of the vital piece of information you forgot that changes everything?  Mistakes like that usually avoid detection until formal acceptance testing.  With pairing, acceptance testing is always occurring.

Like I’ve mentioned, pairing slows you down.  This feels infuriating at first, as you sit there typing, feeling like an ogre who only knows how to type ten words per minute, while your coworker sits behind you mentally tallying all of your flaws.  However, while pairing slows you down in the quantity of the work you create, it speeds up the quality of the work you create.  This leads to less bugs and more time for development as the project progresses.  As an added bonus, I know of no other way that more quickly transfers information between two people than pairing.

Give it a try.  Like Test Driven Development, I was sceptical of Paired Programming, but I’m convinced of it’s benefits now that I’ve tried it.  While every sitation might not call for paired programming, I’m going to be doing more of it in the future and I challenge you to do the same.

Filed in: Programming.


  1. Comment by Karmen Blake:

    Nice and readable. Thanks for the insights. The points you make for paired programming are good. Another reason why teams don’t do it is because their office gives them constraints such as cubicles, small offices, small desks, small displays, etc.

    September 17, 2008 @ 10:08
  2. Comment by Mark:


    Good point about the office constraints. Something you didn’t mention, but that your comment made me think of and that should be asked: do laptops hurt or help pairing?

    I haven’t decided on the answer yet.

    September 17, 2008 @ 10:44
  3. Comment by Karmen Blake:

    @Mark – I have a laptop but in addition have a 24 inch secondary display which I think is a must. The laptop alone would be challenging.

    September 17, 2008 @ 10:51
  4. Comment by Rob:

    Using something like gotomeeting with laptops can provide the ability to do pair programming remotely. I recently discovered it has some really good scribbling-on-the-screen capabilities (though it might be win32 only).

    September 17, 2008 @ 10:53
  5. Comment by Mark:


    I hadn’t given much thought to remote pair programming. That’s an interesting idea, and I wonder how it might help/hurt communication.


    Certainly a larger screen would be a must – or at least the availability of a larger screen. Is the mobility of a laptop a plus, or not much of a big deal?

    September 17, 2008 @ 19:37
  6. Comment by Karmen Blake:

    The laptop and its mobility is a plus. You can always pick the laptop up and move it to a different room or location to work, if necessary.

    September 17, 2008 @ 21:50
  7. Comment by Rein Henrichs:

    Great article. At Hashrocket, we use 30″ Cinema displays with two sets of mice and keyboards. We also use teleport, a Mac preference pane that allows you to move seamlessly from one computer to another as if they were just dual screens. Both of these definitely improve the pair programming experience.

    September 22, 2008 @ 01:46
  8. Comment by Mark:


    I hadn’t heard of teleport – it looks like an awesome piece of software.

    Thanks for the information on Hashrocket. It’s always nice to see how other people are working and I think it helps spread knowledge about what works and what doesn’t.

    September 22, 2008 @ 08:22
  9. Comment by Karmen Blake:

    teleport looks very useful. gracias.

    September 22, 2008 @ 10:09
  10. Pingback from Dev Blog AF83 » Blog Archive » Veille technologique : Django, python, W3F, passé et futur du web, lib JS, PHP…:

    […] http://www.programmersparadox.com/2008/09/03/paired-programmings-benefits/ : l’intérêt du Peer Programming es bien expliqué dans cet […]

    September 24, 2008 @ 04:38