I don’t think engineers are very good at pairing. I know I wasn’t, and it was a big reason why I took my previous job at Carbon Five where I was pairing all the time. In addition to being a well respected shop, I thought forcing myself to pair all the time might improve my ability at working with other developers, explaining concepts to others, and might even make my job more enjoyable.
I should mention before I go further, this post is not necessarily advocating Carbon Five’s pairing philosophy nor admonishing it. These opinions are my own.
Truth be told, as much as I wanted to like pairing, trying it was something I hated. In previous attempts, I always wanted to grab the keyboard and show my pair how to do something rather than attempting to articulate it. Worse we would end up in a debate about how the code should be structured, what the feature should actually do, or even just debate whether real programmers use sublime or vim.
Happily though, my time at Carbon Five certainly helped me to be a better pair. Working with engineers that are very experienced in pairing really helped improve my pairing skill.
Benefits of pairing
I feel it’s worth reiterating some of the benefits of pairing that I found:
- I would leave work happy. Like any engineer, I love to talk about code. Pairing lets me discuss code while not floundering on my responsibilities.
- I could work on any part of the codebase. After an engineer writes some code he naturally becomes the owner of it and nobody else ever understands it. Pairing resolves this and as a result the codebase is understood more comprehensively by all.
- I got way more done. Not being able to tab over to Reddit or email is a big part of this, but it’s easy to get distracted by stuff that is work-related as well. Pairing doubles the number of people making sure you’re working on the specific task at hand. This doesn’t feel like your elementary teacher looking over your shoulder by the way, it’s a lot more natural than that.
- I wrote better code. It’s like you have a human debugger looking right over your shoulder. Testing works especially well here too, while one developer is writing code, often the other is thinking about how to test against it — or the other way around for TDD.
How much to pair?
If pairing simply sounds like working more, you wouldn’t be wrong. Working hard feels great when it’s effective though. Usually companies that pair 100% go home right at 5:00, staying any later would build burnout pretty quick. I think pairing 100% can be too much for this reason. I think for most organizations, pairing 2–4 hours per week is a great amount. It will almost certainly be the most productive, happiest period of your week.
In fact, if your team has never paired, start with 2 hours once per week. Find someone that wants to join (if it’s just one pair the first week, that’s totally fine) and let it build from there. If after the first couple of weeks of 2 hours you feel that you want to do more, move it up to 4 hours, then a full day and so on.
Pair during the full period though. Block it off like a meeting. Don’t answer emails or instant messages unless they are relevant to the specific task at hand. Those distractions can wait and will seriously damage your success at pairing. It’s easy to tell when your pair loses his focus even for a couple of seconds.
Don’t force people to pair. If you want your entire team to start pairing full time, first start by pairing with those that actually have solid interest in pairing. If what I say is true and the pairing engineers are happy and getting a lot done, the pairing naysayers will be begging to join. Keep it a members-only club for as long as you can, I say.
Along those same lines though, don’t pair more than you scheduled. Stop it right when it’s over. Pairing is probably new to you and diving too far in will make it hard to pick it up next week. You probably won’t pair very well and it’ll feel like too much of a commitment.
Pairing is practice
This brings me to my first big point, pairing is a practice you have to do in order to be good at. It’s like any other activity (snowboarding, dancing, playing guitar) you’ll start out unbalanced and rough but gradually feel it out and improve. Don’t expect just because you can program you can pair. Somewhat conversely, don’t expect just because you can’t program you can’t pair either (this comment targeted towards support people, or people looking to become engineers internally).
Pairing isn’t simply two people working on the same machine. It’s an involved process where you’re articulating code, solving problems in your head, writing code and testing it all at the same time. Even when you’re not pairing though, these are awesome skills to be good at.
What you should take away from my point of pairing being practice is that you should make it a routine first. Try to do it each and every week. Don’t expect it to go swimmingly every time, but trust that once you and your team get the hang of it the edges will be roughed out.
Take notes about what you accomplish, what works well, what doesn’t. By the way, this is exactly the kind of information your manager would love to see. The insight that comes out of an activity like this can really help lead a team or even a company.
Pairing Guidelines
Before you start pairing, write up a short, living document (less than 1 page) describing guidelines for you team containing the following:
- Why you are pairing? What’s the goal?
- What tools and techniques do you suggest the pairs use?
- How/When will pairing and matchmaking happen?
This is exactly the sort of thing you should send out to your company announcing you are planning on starting a pairing club too.
Tooling
Engineers spend way too much time talking about tooling in the first place. I’m guilty of this too, it’s just the way we’re wired.
Honestly though, it really doesn’t matter that much for pairing. What does matter is flexibility in tooling. Do not prescribe specific tools that pairs must use. An example of this might be saying that all engineers must use vim. You might even have a good reason such as allowing you to pair over SSH instead of having to use something heavy like Screen Hero. That kind of dogmatism is certainly going to exclude some people and the second you start excluding people, your pairing club is falling apart. ☹
That’s not to say you shouldn’t try things out like SSH pairing over Screen Hero, just that you shouldn’t make it a rule. Pairing requires some experimentation. I’ve even had success using a Google Hangout with a triple-pair where only one person could actually use the mouse and keyboard. Pairing is way more about communication than it is about who’s actually typing code. Having said that, I’ve been very happy with Screen Hero as a good all-around tool. It’s really fast since it directly connects the machines, and having multiple mouse cursors is really nice.
As an individual pair, stay accommodating. Engineers are super attached to their tools. Go out of your comfort zone to try tools you don’t normally use (and really try not to complain about how much you miss your kill-ring). If they use some bloated IDE with stupid refactoring features, let them show you how awesome they think it is how quickly they can rename a class. There’s no better way to make an engineer happy than to let them show you how awesome their tools are.
Experiment on tools, but not too much. It’s easy to waste time here.
Who should drive?
Another place people new to pairing get hung up on is who should be driving, when to switch, is it okay if one person drives most of the time. While you are pairing, the number one thing to keep in mind is “Is my pair engaged?” or “Am I engaged with my pair?” usually the person that’s driving will be more engaged, and switching it is one technique to help bring yourself or your pair back into the action.
It should always be okay to ask for control. Many developers (myself included) struggle with this and tend to want to grab the keyboard. Find what techniques you can to prevent this (maybe even including unplugging your inputs). Ask for control and if they keep taking it back, simply state, “I’m really having trouble following all of this. Mind if I take control for 15 minutes or so? I think it’ll help me get my bearings.” That should be enough of an indication not only to give you control, but should help your pair realize that they’re not doing a good enough job keeping you engaged.
Don’t blame them too bad though, we’ve been working for a long time under the mentality that our objective is to ship code and when we’re not shipping code we’re dead weight. It’s tough to shake that.
Don’t just zone out and especially don’t start checking your email or something. If anything, go for a 5 minute walk to reset. You’ll be damaging the process itself if you feign attention.
Driving is only one technique to staying engaged. Even if your pairing setup doesn’t allow for easily sharing the mouse and keyboard for some reason, you can still pair. Ask a lot of questions about the code “hmm, so what would the value of this variable be here?”, “We’re sure this is returning a boolean, right?” Encourage as much of that as you can get, even if you can share the mouse and keyboard.
Whose project should we work on?
Almost certainly one pair will be more familiar with the part of the codebase you’ll be working on. This is expected. Don’t try to split the time up between “your stuff” and “their stuff”. Spend the entire session on one pair’s stuff.
If it’s your project that you decide to work on, prepare to get a ton accomplished, but also be prepared to work a bit harder to ensure your pair is engaged and following along. Before the session, lay out 2–3 potential tasks and present each of them before letting your pair decide which one to work on. Pass the keyboard as much as you can, even if it’s unbearable seeing them attempt to write code you could bang out in a few keystrokes. Remember you’re just more familiar, not more intelligent. This is harder than it sounds.
If it’s not your project, realize right up front you won’t get anything done during those few hours or maybe that entire day. Don’t try to do it on the side or after work. You’re accomplishing a ton even if it’s not increasing your contribution score on the Github project. Sometimes as engineers it’s hard to remember that we actually can produce a ton of value without actually shipping code. Stay focused on your pair’s goals and try to learn as much as you can about their project. If you do this well, they’ll be very keen to help you out when it’s their turn to pair with you.
Remote vs Local
Local is always better. If local isn’t possible though, remote is totally fine too. It certainly helps to have met the person you’re pairing with in person once before. I’m not sure why exactly, but I feel like I can communicate so much better with someone even if I just shook their hand once.
On equipment, you don’t really need much. A single laptop in on a table works well. I would focus on making sure both engineers are sitting next to each other over anything else. I’ve had setups where I was behind the other engineer and that always feels alienating. You can’t talk behind you that well.
Having a nice pairing station with 2 monitors and 2 sets of keyboard and mice is great, but really only needed if you’re doing all day pairing.
Pairing is Learning
The goal of pairing is always to learn. Whether it’s to learn about the programming language, learn about the company, learn about your coworker, learn about the project, or learn how to pair in general, you should be learning something new the whole time.
For that reason, keep an open mind. Expect to change your mind a bit about what “good” pairing should be. Test out some of my tips, but find out what works for you. Most importantly, realize that pairing isn’t just about you shipping more code, it’s about being a better engineer and building a better product.
