I've noticed the topic of pair programming can be polarizing. Some developers swear by it, while others don't see the value and feel strongly that they can produce better results alone. Wherever you fall on this spectrum, I'm here to convince you that pair programming can serve a purpose in your organization and share how we get the most value out of it at Handshake.
What is pair programming?
For those who may not be familiar, pair programming (AKA "pairing") is simply two developers working together on one computer. There are a number of different ways to achieve this setup, but we typically use Slack (previously Screenhero) to give each person in the pair access to their own keyboard and mouse for the same machine.
Why we pair
The benefits of pair programming have been documented pretty thoroughly. There is even some great research on the costs and benefits, so I won't go into every detail about where you can get value out of the process. However, I do want to highlight a few key benefits that have made it an increasingly important part of how we work at Handshake.
- Knowledge transfer — There is simply no better way to ramp someone up on a project than to have them work with another engineer who has all the context already and can answer questions on the spot.
- Better code – Having someone to talk through your implementation and bounce ideas around with always results in better design and fewer bugs.
- Stronger empathy — Especially since our team is distributed, pairing is a great way for engineers to stay up to date with what challenges their peers are facing and develop relationships.
- Better communication — One engineer has to break down and describe the problem to give the other context. Understanding and articulating problems is much harder than coming up with solutions, which always makes this a worthwhile exercise.
- Higher velocity — The previous points boil down to us improving our team, code, and chemistry, which naturally means we are more productive than we would be without it.
"I learned so much about the best practices and incredibly useful shortcuts that ended up saving me so much development time. The culture of pair programming at Handshake is central to its healthy, collaborative engineering culture and also speaks greatly to one of the company’s core values (Learn. Grow. Repeat.) that promotes collaborative learning and growth."
Mitchell Kim, Handshake Summer Intern
When we pair
Some companies have found success having their engineers pair full-time. This seems to work well if there is a lot of overlap in the responsibilities for both people in the pair, but it doesn't seem to leave much space for keeping up with anything outside of feature work.
We encourage engineers to contribute in areas of the product they are passionate about and even have many people pairing across different teams. This is great for spreading knowledge about different areas of the product and exposing engineers to the challenges their teammates are facing, but having such a variance in responsibilities between members of a pair makes it difficult to schedule longer sessions.
We also recommend not pairing when working on repetitive or relatively straightforward tasks. Our goal is to maximize the impact of the time people spend pairing and we actively look for opportunities to do that. Some common places we have seen pairing add a lot of value are when:
- A developer is working in an area of the app where they don’t have a lot of context (this is most of the time while onboarding someone)
- There isn't a clear path forward and multiple options need to be evaluated
- Working on complex problems
A note on onboarding
We feel that there is no better way to get a developer up to speed on a project than to have them pair program. No matter how well your code is structured or your onboarding documentation is written, there is still so much value new team members get from working with other people who know their way around the codebase.
Engineers who have been around longer can not only provide missing context, but also encourage new members of the team to act in ways that are consistent with the rest of the team's values. This is the fastest way to show someone your team's way of doing things, which is essential for maintaining culture while growing your team. Please don't take my word for this, take Ben Horowitz's.
"What is Culture? It’s the collective behavior of everyone in the organization."
Ben Horowitz
How we pair
Aside from making sure there is a level playing field for each pair by having the same access to the computer, there a few things we feel are key to a successful session. We feel the following guidelines provide a lot of value for our team given our goals of maximizing production while making sure we expose ourselves to a variety of pairs:
- Set goals — Just like you wouldn’t want to walk into a meeting without an agenda, make sure to prepare and agree on what you want to accomplish as a team for the session. We don’t schedule long sessions, so it’s important to go in with a plan and be ready to dive in.
- Take turns — It’s easy to get caught up in a problem and not take turns driving and navigating. Try to evenly distribute ownership of these roles and consider setting a timer for when you’ll switch if you have trouble remembering.
- Mix it up — Don’t be afraid to pair with different people on a regular basis. Be on the lookout for good opportunities to pair with people across different teams.
- Do more than write — Share tips and tricks to help maximize efficiency, break apart complex problems, or try doing pair code reviews.
How do you pair?
We don't believe there is a right or wrong way to pair, and it's certainly not a one-size-fits-all practice. We are always looking to improve our processes and would appreciate if you shared some of the things that have or have not worked for you and your team. Please reach out via email (chris@joinhandshake.com) or Twitter (@ccschmitz) if you have a story to share.
Interested in being a part of a team that puts an emphasis on pair programming and continuous improvement? Come join us!
Editor’s note: This post was originally published in March 2020 and updated January 2021. Click for our most up-to-date job openings and engineering blog content!
Photo by Christina Morillo from Pexels