Reno, NV    +1 (800)0 621-0871

Go back


My Experience with Pair Programming

  |  April 17, 2012

Here at Aelogica, we pair 95%(or more) of the time. As the first developer here to join Steve, I experienced and learned A LOT from pairing – either with Steve or from my colleagues. The first time we paired, I was still part-time, so the session was just a little under four hours long – but I felt like I have coded the whole day and I had a week’s worth of experience under my belt.

A bit of a backround: I was more of a front end Rails dev focused on HAML/SASS and I knew about intermediate Rails concepts. I knew the basics, but was not able to do metaprogramming to save my life. In any case, after my first week of pairing, I felt I had learned a month’s worth of experience already.

This trend continued when I finally jumped in full time. Eight full hours of pairing felt like I was thrown in the sea to learn how to swim when I was only training on the 6-feet end of the swimming pool. I never knew that I could go on that pace for eight hours. I usually go on bursts of two hours until I’d take a break then go on again. Pairing wasn’t like that – it was very tiring since you’re on fifth gear the whole time.

At that time, I thought I’d burn out but a project came to us where I had to do it alone while Steve did some other project. This was a bit of a breather, but at some points where I needed help, Steve was always ready to jump in and help out.

Today, there are eight of us and we still pair every day. It makes life easier for us. Whenever I feel lost, as everyone does at some point, my pair is usually be able to explain and make everything clear again. Of course, when I think my pair is lost, I suggest we both go to the whiteboard to visualize the problem and the solution. Pairing now has become such a normal part of our workflow that whenever we’re alone on a task it feels so dull. The day seems to slow down, the task gets harder (even if it’s not) and your brain drains faster.

Without a pair, you feel like a hermit crab without a shell. You feel less certain. “Am I really on the right track?” “Did I leave an obvious bug in there?” “How should I fix this?” It feels a little strange to get so accustomed to working in pair. I still code alone sometimes but when there a big project awaits with an epic new feature to build or a new critical bug demands attention, I prefer to tackle it with a pair. I don’t think this is a bad thing – since we’re dealing with large projects that clients and customers use, I wouldn’t want to break it or commit a grave mistake. Pairing makes you more careful than you might be by yourself.

It’s better to have a second set of eyes to catch details you can easily miss. Sometimes you process things too fast (or too slow) and you can overlook or forget things that might break half of the app. When dealing with inherited legacy code that might not be fully tested, it is especially important that someone else checks what you are doing.

Looking back on the last year and a half at Aelogica, working primarily in a pair configuration, it is hard for me to imagine doing it any other way.