How and Why We Pair

By Tony Dewan

Over the last few years, most of the product teams at Expected Behavior have transitioned to near full-time pair programming. Along the way, we’ve been prototyping a room setup for pairing that we’ve found to be really effective. Since we’ve recently added a team and expanded our office to include a complete pairing room for each team, it seems like a good time to share the details of our setup.

Pairing?

If you’re not familiar, pair programming is really just two people programming together on the same file/task/project. There are two roles when pairing:

1. Driver. This person is currently typing. They are usually directing the flow of work.
2. Navigator. This person is not currently typing. They are a sounding board, a second set of eyes, a source of knowledge, and a generator of ideas and alternative approaches.

These roles should be fluid and switch between people. The navigator isn’t checked out! They should be actively engaged.

With two people working on the same thing at the same time, it seems obvious that pairing makes things take longer. While true, we find it to be much less than 2x. Still, if it takes longer, why do it?

But Why?

We pair for a few reasons:

1. We like it. It might not be everyone’s thing, but we enjoy working in real-time with someone else on difficult problems.
2. We tend to get better outcomes. Sometimes it’s project planning, sometimes it’s developing a technical architecture, and sometimes it’s just writing tests. No matter what, we find pairing results in more complete, robust, and well-engineered projects.
3. We learn a lot from each other. Not everyone uses the same tools (terminals, shells, text editors, etc), and pairing allows us to see how other Behaviornauts do things. This admittedly drops off over time, though team rotation and our penchant for trying new things tends to keep it interesting. Beyond tooling, everyone thinks about problems a little differently and brings a different set of experiences to the table. By pairing, we get more aligned on things like when to break code out into separate classes, which, over time, makes code review easier and reduces friction.
4. It’s a great way to keep up with culture transfer and maintenance. Pairing is a very high-bandwidth interaction, which naturally supports inculturation of new team members and helps with culture drift.

That’s not to say there aren’t downsides. As mentioned above, pairing can make projects take longer. It’s very draining, and usually more so for introverts. It also requires that pairing team members have overlapping schedules, which can be hard for some teams. Still, we think the downsides are more than made up for by the benefits…assuming you’ve got the right room layout and technical tooling in place!

The Room

The naive approach to designing your pairing space puts two people side-by-side looking at the same screen. With this approach, you can easily take a laptop into any work room or conference room and get to work. It has some important downsides for us, though:

1. Not everyone has perfect vision, which makes it hard for the navigator to see what’s going on. This makes it easy to check out or get lost.
2. Even with perfect vision, long pairing sessions become ergonomically problematic if you have to crane your neck to see the screen or type sideways.
3. With only one computer, the navigator has limited means to remove roadblocks. Looking up documentation, duckducking error messages, grep’ing the codebase…these all become roadblocks when you have only one computer.
4. If you pair full-time, you spend a non-trivial amount of time not programming. You might be discussing high-level architecture, prioritizing todos, working project management problems, etc. Sitting side-by-side isn’t the best layout for this kind of collaboration.

You can solve #3 by adding another computer, but that just adds more problems:

1. It’s easy for a navigator to get distracted, and it can be difficult to tactfully call out a distracted partner.
2. The driver can’t see the navigator’s screen without introducing 1 and 2 for both parties, making roadblock removal high friction.

Other solutions, like mirroring screens on wall-mounted TVs, solve some problems but not others.

Here’s how we solve for all of the problems:

The key takeaways:

1. Each person has a desk and the desks face each other.
2. Each desk has a second monitor positioned to the side. The second monitor is for mirroring the other person’s screen.

This setup allows both people to ALWAYS see their partner’s screen, which reduces the possibility of a distracted navigator and makes it trivial for the navigator to remove roadblocks. It also solves the vision and ergonomic problems: it’s no longer necessary to crane your neck, and you have total control of the other person’s screen location, zoom level, etc. Finally, the desk layout and monitor placement allows for direct, face-to-face discussion as the primary interaction.

We’ve found this layout, combined with the details described below, makes for comfortable and effective pairing sessions.

Second Monitor? How Do?

So, how do we get the other person’s screen on the second monitor? The easy answer is to just have them plug into it and turn on screen mirroring. This isn’t a bad option, but we like to use the macOS built-in Screen Share utility (which is really just VNC) instead. We’ve found using Screen Share has some benefits:

1. The navigator can take control if desired. This is great for showing unfamiliar syntax, highlighting something hard to see, etc.
2. Either party has total control of the zoom, scale, and placement of their partner’s screen.

Technically, we simply connect the monitor on our own desk as a second monitor and put the Screen Share window on the second monitor (leaving your laptop as the primary workspace, which your partner can see once they’ve done the same dance.)

Note: you need to adjust your macOS sharing preferences to allow this. We like to use this setting since it means we don’t have to deal with passwords, and it gives you complete control to accept or reject at any time.

After that, you’ll need to initiate a Screenshare. This requires your partner’s computer name from the Sharing preference pane. Just append `.local`:

Then select “By Requesting Permission” on the resulting dialog.

It might seem complicated, but it’s pretty smooth in practice. The downside is that if your local network has problems, then Screen Share can be buggy. It’s easy enough to fall back on the other approach if necessary. A buggy local network probably limits your effectiveness, anyway. Or maybe it’s time for a break to reset the router!

Tips!

Ideally, only pairing happens in the pairing room. If you’re in an open office situation, this layout is probably going to be problematic for you. We retain a mix: everyone has their own desk in an open office area, but we have enough pairing rooms for every team.

Another thing: hardware consistency is important here, especially with monitors. If you can, get the exact same monitor for both desks in all rooms. Having the exact resolution, size, and display settings makes the rooms interchangeable and limits the friction of getting set up. If you also always put the monitor on the same side, then macOS will remember the display location as well!

Don’t forget a white board! We also like to keep a pile of paper and sketching tools in each room.

Remote pairing?

We don’t do much remote pairing right now, as we’re all located near our office. We’ve used Zoom for the rare remote pairing session in the past, but that tends to skew more toward a meeting style of work rather than collaborative building. However, we’re excited to try tools like Tuple and CoScreen next time we have the need!

We’ve had a lot of success with this approach, so hopefully it’s helpful to you. If you have a different approach or other ideas to make smoother pairing sessions, we’d love to hear about it! Hit us up on Twitter: @eb or @tonydewan.