This is the second post in our ongoing series about remote work and engineering. Check out our first post, Tips for engineering managers learning to lead remotely.
As more companies shift to remote-first or all-remote work, engineers may be feeling the loss of their teammates' company. The good news is that unlike other forms of in-person collaboration, pair programming translates really well to remote work, and in some cases is even more effective.
Our support engineers do regular pair programming on tickets, and many speak of it as a highlight of their work weeks due to the social element of the calls, as well as it proving more efficient for some troublesome tickets. (We'll dive into why, but feel free to jump to our tips for effective remote pair programming if you prefer!)
What is pair programming?
Pair programming (sometimes referred to as paired programming) is an agile, collaborative software development method done between a team of two developers that each take on an individual role. These roles are called the driver and the navigator. The driver works directly at the computer while the navigator concentrates on the overall programming direction.
The purpose of pair programming is to design, code, and test user stories all on one computer. Although the driver is the primary teammate at the keyboard, this system requires that each developer role have equal time and responsibility to complete their part of the development. The driver writes the code and the navigator reviews it, and these roles can be switched between the two teammates as needed.
It's more than just work
Ronald van Zon, senior support engineer, explained that pair programming provides an opportunity for team members to chat about their lives outside of work, instead of focusing solely on outstanding tickets.
"You see someone face to face, so you might ask them, 'Hey, how was Christmas? How are you doing?' If they have something going on in their private life, the next time I see them I will ask about it, so there's a social aspect to it."
"It's a lot of fun. In cases where you're really focused on work and you have a very difficult ticket, it's actually very nice to have someone there just to throw your ideas at."
You see the problem more clearly
Instead of relying solely on your judgment, programming in pairs means your teammate might ask you questions about something, introducing ideas you hadn't necessarily thought of, and identifying gaps you would otherwise miss.
"For example, we had one very long-running ticket, where we'd tried a hundred thousand things already, and weren't sure what to do next," Ronald says. "Just by talking with a group and explaining what the situation was helped me realize what the next steps should be. I could have looked at that ticket the entire day and wouldn't have come up with it on my own."
Senior support engineer Arihant Godha explains another scenario where pair programming paid off in a big way. "In one of our pairings we worked on a complex customer issue related to merge trains, where we did a multi-cross-team pairing and identified the crucial issue which was a blocker for one of our biggest customers. We didn't just identify the problem, we also found the workaround for it until our developers were able to deliver a fix."
You can pool your knowledge
As the saying goes, two heads are better than one. Pair programming allows engineers who may be experts on different things to come together to tackle a single problem.
"Pairing on tickets is a great way to collaborate on problem solving," says Cynthia Ng, senior support engineer. "It’s especially useful at GitLab, where we have a single product that covers a wide variety of areas, because each person has expertise on different parts. Seeing how others approach and solve problems can also greatly inform your own work as well."
Support engineer Anton Smith agrees: "I find that I learn and absorb so much knowledge just from conversing with another support engineer in a pairing call."
You get to the best solution
"A problem can have multiple solutions and multiple approaches to solve," says Arihant. "Sometimes ticket pairing gives you the best approach to solve a ticket. It also helps you in learning and sharing knowledge. For example: If you can ask for all the required information in one ticket response rather than having lots of back and forth, then it’s a great user experience."
Cynthia shares a specific example from her past experience with pair programming. "Davin Walker and I paired a couple of times on getting trials and their expiry dates showing on the admin side of GitLab’s Customers Portal. The merge request is meant to help improve our team’s efficiency in handling SaaS trial-related requests. Pairing really helped to work out the scope of the issue and what we could ship as the first iteration."
Benefits of pair programming
The benefit of pair programming is that there are two sets of eyes to help review the code being produced to ensure that it is as good as it possibly can be. This is commonly known as the four-eyes principle.
This leads to other benefits, like…
- Reducing the number of coding mistakes
- Becoming a better coder overall
- Learning from another experienced developer as well as learning from the mistakes made during a project
- Building better collaboration skills
This system also breaks up the development project into smaller, specifically defined tasks under the agile project structure.
Why remote pair programming works
In speaking to our remote pairing fans, it's clear that pair programming is a form of collaboration that doesn't lose anything by being conducted remotely.
"It's no different from sitting next to the person. In fact it gives you a better view to look at and find better approaches simultaneously without wasting any time," says Arihant.
"I’ve done pair programming in person and I actually find it easier remote because of screen sharing," explains Cynthia. "You have more control over what you’re looking at and how, whereas in person, often the main thing you’re working on together is on one person’s screen."
How to get the most out of remote pairing
1. Know when to pair
We've focused on tickets so far because our support engineers at GitLab are our biggest remote pairing advocates. Support engineering often involves debugging a customer problem, so it tracks that pairing would be useful (compared to developers who are usually focused on building something). But really, any developer can benefit from pairing when stuck on a problem.
Ronald worked as a developer for more than 15 years before joining the Support team at GitLab, including a year spent as the only developer for an entire company. "One thing I learned really quickly was that if I was stuck on a problem, essentially, I had no one to talk to, which made things difficult."
Working in isolation, without the distractions of the office, is great when you're in the zone. "It works until you run into a difficult problem to solve," says Ronald. "Spending three days on a problem, before getting to the single line of code that solves it, sucks." If you find yourself not making any progress on a challenge, it's probably time to pair.
2. Go in with a clear agenda
Out of respect for everyone's time, we recommend that every meeting start with an agenda, and scheduling a pair programming session is no exception.
"I think it’s important to set expectations or goals for the session. It can be fairly general like, 'explore what options we have,' but the key is to make sure you’re on the same page about what you want to do during the session," says Cynthia.
Arihant agrees: "The agenda should be set beforehand so you have enough time to understand the problem statement." Otherwise you might spend 20 minutes reading through tickets or bug reports before landing on something to work on together.
3. Tackle bugs one at a time
"Take one problem at a time and try to reproduce if you are trying to solve a bug," Arihant recommends. It might be tempting to try to solve more than one problem if you think they're connected, but you really won't know that until you fix the first thing.
4. Speak up!
This goes for remote or in-person pairing: speaking freely helps to get to the root of the problem more quickly. "Don’t be afraid to voice your opinion," advises Anton. "Even if something is wrong, it helps eliminate the cause of a problem and it might spark alternative ideas."
How we do remote pairing
At GitLab, we have a mix of ad hoc and scheduled pairing sessions. "Pairings are required as part of the Support team onboarding, and we also have a support Donut app channel that people can join to decide who to pair with," explains Cynthia.
Having recurring pairing sessions can help engineers stay connected with their teammates, says Anton, but spontaneity can be helpful if you're swamped or get stuck on a problem: "If I am working in the queue to stop tickets from breaching, sometimes I will publicly post my Zoom room link in Slack and allow anyone to join."
Arihant says, "If I want to pair with someone I simply ask them in team chat or simply send them a calendar invite. If it is for a specific topic or group, then I check the area of focus or skills by person pages to find the best person to partner with."
We also have a dedicated issue tracker for support pairings so team members can track who they've paired with and on what.
Keep an eye out for the next post in our series, where we'll be sharing more remote collaboration practices for engineers.
