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.