On Pairing

This past week was intense. This past week . . . I paired.

A couple of weeks ago, my good friend and team lazer partner, Mike (mrb) proposed that once I was done launching in January we should do a couple days of side by side programming on the big client project he has been working on. There’s been a lot of talk about Pair Programming in the Ruby and Rails community lately (here and here) and I can say honestly up until now, I didn’t really ‘get it’. Sure, it helps to have someone check your code but isn’t that just cutting each developers productivity in half? I couldn’t really understand how two programmers working on the same thing at the same time could produce more work then two programmers working separately. I was looking at the wrong equation.

What I thought:

1 nerd working alone = ~1000 lines of code a day
2 nerds each working alone = ~2000 lines of a code a day

2 nerds working together = ~1000 lines of code a day

What I left out:


Sure, two programmers working separately can produce a lot more work product if work product is measured in shear volume. However, what I discovered, is the code we produced working together was cleaner, faster, and more acurate then what we could have produced in the same time apart.

When we decided to go for it we set out some initial goals: What did Mike want to achieve in two days?

  • Speeding up some slow actions
  • Fixing some broken pieces
  • Cleaning up some repetitive code

It seemed reasonable. I came up with a plan of action:

  • Get a tour of the codebase
  • Find a good place to start
  • Branch the codebase
  • Add test coverage
  • Tear things apart

And so it was coded.

In two days we managed to add a small but solid test suite to the linchpin actions, reduce the controller time in most places by 400%, and delete a ton of code. It felt really good. By doing this as a Pairing session instead of just me grabbing code and working on it alone we both gained a ton. It was the small pieces of this experience that I didn’t think initially about that made me realize how powerful pairing can be.

Lack of Distractions/Extreme Focus – Because we were sharing a single computer and both staring at the same piece of code all of the common things that would derail a work session (Email, AIM, Twitter, etc) werent even available. After the first day we stepped back and realized that besides the break for lunch and some coffee/water breaks, we worked the entire day.

Code Correction/No Shortcuts – Having someone look over your shoulder provides not only the constant spell check (something I need) but also forces you out of the habit of shortcuts or cutting corners. A physical manifestation of your conscience, your partner wont (or at least shouldn’t) allow you to write the crappy code to just ‘get it done’. In this way, after all was said and done, not only did I feel extremely productive, but I felt like I wrote great code.

Social Hacking/Learning – Working from home for the past little while and then jumping into this made me realize that constant human contact for me is a requirement. It puts me in a better mood as well as keeps me focused. I also enjoyed the give and take of this relationship.

In an ideal world, I suppose your Pair partner in coding is a rough equivilient of a Detective’s partner. They back you up when there’s heat; They make sure you’re not taking cuts under the table; They keep you on your toes.

Well, something like that.

P.S. This week I hope to post some of the better refactoring patterns/examples discovered in our sessions.

One Response to “On Pairing”

[…] of idioms we used to clean up in last weeks pair-refactor is a pretty common one that most ruby developers are familiar with but developers coming from […]


QuirkeyBlog is Aaron Quint's perspective on the ongoing adventure of Code, Life, Work and the Web.




QuirkeyBlog is proudly powered by WordPress