In the summer of 2013, CoverMyMeds had agreed to write a workflow system called Central. Due to a few miscalculations, we ended up with far less time than we’d wanted, and found ourselves in the classic “too much to do / not enough time to do it” dilemma.

One of the techniques we used to help us get through this was pair programming, a classic software building technique where two developers work on the same thing at the same time. If this whole concept is new, Wikipedia has a typically bland description, c2 has a more irreverent but potentially more helpful analysis, and there’s tons of books that can help you get off the ground.

Here’s how we did it during Central’s formative first few months: my pair, B, and I would sit at a table. B would be in front of a computer, and I would be in front of a keyboard/mouse/display connected to that same computer and mirroring its display. That computer had Central’s code checked out and working development environment set up. It also had an editor set up in a way that both B and I could use it.

Typically we’d ping-pong — one of us writes a test that fails. The other person then writes the implementation that makes the test pass, then writes the next failing test and passes control back. While one person is busy typing, the other is reviewing the code live, making suggestions for improvements or asking questions.

That’s a fine technique, but it doesn’t always hold up. Sometimes, if one person had a solid vision in their head for where to go next and the other didn’t, we’d just let the one person keep control for a while. This isn’t a good way to work long-term, because one person ends up a passive observer eventually, but it works well when the pair is trying to get unstuck or one person knows a language/module better than the other. I learned a ton by watching B work in libraries I hadn’t had a chance to use yet.

Also, when one person is having a shit day and isn’t able to keep themselves focused, the other can gently nudge them into participation. Maybe I stayed up too late and now I’m cranky and tired. Having your primary display be someone else who’s working on the thing you’re both responsible for means it’s hard to spend 40 minutes reading ancient jwz blog entries, especially when someone’s just written a new test and is asking you how you want to write the implementation.

We both had our personal laptops off to the side, so we could monitor incoming email/IMs, or handle personal business. You can pair on one person’s personal machine if you connect up a second keyboard/mouse/display to it, but that always makes me nervous. My development environment probably won’t be immediately useful to you, and I’m constantly anxious about an embarrassing personal message notification popping up. Having a neutral third machine was incredibly helpful, but it did require that we shared an editor or IDE. We got lucky, since we both used a similar vim setup we could just pick one and run with it, but that can easily be a huge stumbling block if you’re not that sympatico.

We did have a strict pairing policy, if we were both free and in the office we’d be pairing. This helped us keep focus. If one of us was out at a meeting or something, the other could take solo duty and keep forward progress going. Sometimes I’d take the opportunity to take my personal laptop into a common area, chill myself out, get some of our stuff done, and push it up to a branch we could later pull down on our pairing machine and review together.

You can do this kind of pairing remote, but as with all things remote, it’s not quite the same. Input lag for the remote party can range from “annoying” to “this is impossible screw this,” and even the best video conference isn’t a replacement for being right in the room with someone. That said, it’s not impossible. If you can’t find a neutral third machine to screenshare into, alternate who hosts the screenshare each day, and be strict about communication — my experience with remote pairing is that it’s too easy for person sharing their screen to just keep control for most of the session, with the occasional “hey this look good to you?” That’s no way to pair.

When we first suggested to our manager that we ought to pair on Central, he was skeptical. He expected two developers working in parallel would double our throughput, even though I know he’s read The Mythical Man-Month. And he wasn’t necessarily wrong, two developers working independently will produce more software than if those two pair, no doubt. I thoroughly believe that we’d have ended up with an awful train wreck if we’d both independently went off and tried to build out this new system. We had to learn a lot about our customer’s workflow and business requirements, and having us both on the same page was invaluable.

Finally, some folks are insistent that entire departments should pair, and that the pairs should be rotated every n days, usually at the end of a sprint or something. That can do a lot for team development and shared understanding of different codebases, but we didn’t do any of that. We needed to build and ship this software quickly, and if we’d been forced to rotate, we’d be putting team dynamics above providing value to our customers. At this stage in CoverMyMeds’ growth it wouldn’t have made any sense.

So yeah, don’t be afraid to try pairing.

Published by Jon Canady

I'm Jon Canady. I was one of the Founding Engineers at a company called CoverMyMeds, and I helped build its technology and teams until our acquisition in 2017. I like helping companies figure out how to scale their engineering teams and practices. If you want to chat about how I can help your company, or you just want to grab lunch sometime, I'd love to hear from you!