If you read tech blogs, then you’ve no doubt come across pieces talking about the benefits of pair programming. It can seem counterintuitive at first. After all, you have multiple developers working on one thing. How can you expect to get enough done if you are dividing your labor? But at Upstatement, we’re strong believers that it leads to more velocity, a better understanding of the code base for everyone, and higher team morale. The merits of pair programming became especially apparent while working remotely—we’re sharing our process so other teams can reap the benefits we’ve seen.
Pairing can be more than 2 people
We often have “mobbing” (sometimes called “swarming”) sessions, which is one person driving with multiple people navigating. This might feel intimidating at first, and it can take a while to figure out a good cadence, but there are two huge benefits to having more people on the call while building something complicated. First, it (ideally) gets the team more comfortable with each other. Second, more people walk away understanding how that piece of functionality works. This is key when working on new features or in a new tech stack.
It’s ok to joke around
Pairing is supposed to be fun! Or at the very least, it isn’t supposed to be stressful. It’s ok to go off on a tangent as you look up the name of a movie you were thinking about or talk about your favorite ramen restaurant. This is especially true in a remote setting, where you don’t get many opportunities for organic, social conversations with your coworkers. Stay professional (just like you would in person), but don’t be so stilted and take the thing so seriously that the pairing session feels like a trip to the DMV.
If you find yourself dreading pairing sessions with people, don’t torture yourself! Opt out of it and don’t force yourself to sit through a call where you share your monitor if it creates stress in your life. Pairing is about personalities; you simply might not mesh easily with a group project. Do not force it if it isn’t working. Sometimes, it just isn’t going to feel right. And accept that you might not be up for it every day.
Make pairing/mobbing open to everyone
On every project, we have a Slack channel that’s completely dedicated to pairing. When you’re ready to hop on with someone, we start a zoom call in the channel, so anyone else can sit in or help. This not only opens up communication to the team, but visually shows what people are working on. And this shouldn’t be restricted to engineers. Our designers often hop on these calls because it’s a fast way for them to ask a question—or just because they enjoy the chatter/socializing. Emphasizing that people can opt in or opt out takes pressure off of the experience as a whole.
Again, pairing is supposed to be fun. Well, “fun-for-work” fun, at least. So don’t restrict it only to the people working on a certain ticket. Keep it casual—no scheduled meetings or calendar invites for people to dread. This makes it feel less intimidating.
When people join the call
We can be a bit asynchronous with our calls, and not everyone joins right away. If you hop on late, say hi! Zoom doesn’t do a great job of alerting you when people join, so letting everyone know you’re there saves them from the awkward surprise when you chime in later.
If someone does join the call late, try to summarize the problem you’re working on to get them up to speed. It might be different than where the discussion left off in Slack!
Take breaks
When tackling a really perplexing issue, there’s usually a point where you’re all staring at the screen having lost the ability to read language or make small talk, much less solve problems. Remember, your brain is connected to your body. Stretch, drink water, or eat a snack. Many of our pairing a-ha moments have come directly after a break.
When is pairing best?
Pairing on every single ticket isn’t possible. People have different schedules and obligations and because pairing sessions require a lot of focus, it can be exhausting if you have to do it constantly. Identify when pairing/mobbing is most useful and prioritize those times.
One of the most crucial times to pair is when onboarding a new team member. This could be someone just starting on the project, or someone who’s new to a particular technology or piece of the stack. This gives them a chance to ask questions and it gives the driver a chance to cement their own knowledge.
We also find that features with a lot of unknowns are a great time for pairing and working together. It might seem odd to hop on a call so you can all do research together, but it leads to a better understanding and everyone can be involved in coming up with a solution.
Finally, tricky debugging can be a great opportunity to hop on a call together. Debugging can be tedious and time consuming, but it’s also a skill that takes a long time to develop. Seeing how other people debug issues can be enlightening. You’d be surprised just how much you can learn!
Roles when pairing
There are typically two roles when pairing.
- The navigator—they aren’t actively writing code but are watching and “navigating” as someone else drives
- The driver—they actually write the code and respond to instructions from the navigator
As the Navigator
Try not to nit-pick
Don’t interrupt: this small piece of etiquette helped our pairing sessions run way more smoothly. As a navigator, it can be really hard not to say something when you notice they have a typo or see the driver is calling the wrong function. But remember: they will see that when they try to actually run the code. The important thing is that they can finish their thought uninterrupted. If you pull them out of the zone because they forgot a semicolon, then you could derail their train of thought right as they’re on the brink of a solution.
Remember: you make those mistakes all the time when you’re programming by yourself and somehow you still finish your work. So don’t harp on those minor things in the moment—they’ll be caught later!
Make mistakes openly
We’ve found that people are afraid of trying something that they think might not work while others are watching. It can be intimidating, especially when you can’t quite articulate why you want to do it. But making mistakes, failing, and iterating is part of the process and being open about that with your team helps to foster the idea that it’s ok to experiment and it’s ok to fail!
Again: you do this all the time when you’re programming by yourself. We learn more from our mistakes than our successes in programming, so don’t be afraid to try something you think might fail. It’s good for everyone to see the failures along with the successes.
The way you do it isn’t the only way to do it
This is true in PR reviews as well as pairing sessions: the way you would solve a problem isn’t the only way to solve a problem. One of our instincts as a navigator in a pairing session is to steer people toward our own solution. If someone throws out an idea that contradicts your instinctive approach, take a step back and let it play out. Be open to other solutions—this is how you end up learning something!
Share the knowledge
Sometimes it feels like you have a more passive role, but it doesn’t have to be that way! It’s really easy to zone out and lose the thread in pairing sessions, so stay engaged with what’s going on in the code. Use line numbers to point the driver, look up documentation so they don’t have to, and try to strike a balance between supplying thoughts but also giving the driver some air. If the person you’re navigating is a junior developer, share IDE or Git secrets you’ve picked up in your years on the job. It might slow the flow down but it will be invaluable in making your teammate a better coder.
As the Driver
Ask questions
Some pairing sessions are a couple minutes, some can last a couple hours. Being comfortable with pushing and pulling branches in Git means no one has to navigate or drive for long sessions (unless they want to). If you’re driving for someone who’s more familiar with the codebase or with coding in general, don’t be afraid to ask questions early on if you don’t understand a piece of logic. Better than pretending you know and then completely missing the point later on. It might make you feel like a dunce, but just remember that your teammate was in your shoes once!
Find the timing that works for you
Some articles recommend having a timer and switching drivers regularly. We found that didn’t make as much sense in a remote setting; a good cadence for us is one driver per feature. This leads to a strong sense of ownership while feeling supported by your team.
Final thoughts
Overall, our pairing cadence has been really effective in bringing the team closer together while we’re all remote. It’s led to more openness and willingness to ask for help, and has made our team more social since we talk every day. We’ve found pairing leads to a better onboarding experience for new engineers, and to learning opportunities for existing ones. Over time, our projects have become more efficient, and in our transparent, collaborative environment, we’re doing some of our best work.
