Frequent pair programming isn’t a practice that our team employs on a daily basis, but I'm a believer in its benefits. Pairing is especially helpful with distributed teams because it connects people who may otherwise feel isolated. I believe that pairing is an essential tool that can be used to get unstuck.
There's no shame in asking for another set of eyes on a project. Sometimes, however, it can be hard to know when it’s the right time to ask for help, especially when everyone on the team is in a different time zone. When is it the right time to ask someone to pair program with you? When is it the right time to work out problems on your own? Right now, one of the challenges our team faces is figuring out when to interrupt someone for help vs. when to stay in the zone.
Introducing the 30-minute window
In order to encourage more pairing and less stuckness on our team, we're introducing what I'm calling Pair:30. During this 30-minute timeframe, asking for someone to pair with you on an issue is actively encouraged. Everyone on the team is expected to say yes to a request to pair.
Our goals here are to...
- Minimize the disruption to flow for all engineers. For our distributed team, this happens to be in the morning for some engineers, and in the evening for others.
- Provide an opportunity for engineers to request/offer help to blockers or stuckness, which are revealed at our standup meeting.
- Remove blockers that might cause someone to hesitate to ask for help, such as:
- A teammate is in the zone and does not want to be interrupted.
- A teammate is asleep, eating dinner with their family, or otherwise taking time away from work.
- The belief that if you just push for 15 more minutes, you'll figure it out on your own. You've taken a quick break for standup anyway, so now’s probably a good time to ask someone else to take a look at your code.
- Foster a culture of pairing. This seems like a good place to start.
How it works
For the 30 minutes directly after our daily standups, everyone on the team is actively encouraged to ask for a teammate to pair with them on an issue. Everyone on the team is expected to say yes. Since this 30-minute session takes place immediately after an existing meeting, our engineers won’t have to carve out an additional chunk of their workday to pair up.
During today’s standup, Erik mentioned that he needed some guidance on a PR he’s been working on for a custom client project. Since Mike was the last person who touched the code, Erik asked him to pair. Once the standup wrapped, Erik and Mike stayed on the Zoom conference to solve the problem together. In this particular Pair:30 session, Erik shared his screen, and the two reviewed code together. Erik left the session unblocked, while Mike left the session having helped a teammate.
While this 30-minute window does help to minimize some of the reasons someone would hesitate to pair, it's not a silver bullet. Forcing people to spend time with each other when they don’t want to is never a good idea, so that’s why we don’t do Pair:30 if no one asks for help. And of course, schedules are always a challenge in a distributed team, so we ask teammates to be respectful of each other’s time zones and locations.
I highly encourage you to incorporate a scheduled time for pair programming, especially if you’re a part of a distributed team. Start by exploring how it might benefit your work and your team. Then, look into tools for remote pairing like Screenhero (which has now completely integrated with Slack), or CodePen Pro, which features a collaborative editing feature.
What are some reasons you might ask for help? What are some reasons that might cause you to avoid asking someone to pair with you? How do you enjoy pair programming? I’d love to hear your thoughts. Leave a comment below or reach out to me via our Gitter chat.