Emmanuel Pinault’s appreciation for paired programming grew after he crashed a software service.
At his last job, Pinault was working on a similar but different feature as another developer, and Pinault’s coworker wasn’t interested in talking about how their items would ultimately integrate. When the time came to join their features, the two ended up sacking the company’s system, taking down the service as they forced two products into one, Pinault said.
“There was no cohesion in the team. It was like, ‘I work on this part, you work on that part,’” Pinault said. “I don’t like to say ‘I told you so.’ That’s not the proper approach. But I feel like we all must collaborate and own the responsibility.”
Now a principal software engineer at Outreach, a Seattle sales engagement software company, Pinault constantly talks up the importance of paired programming to his 13-person team. Normally, every developer he oversees partners with another member of the team, often remotely, mentoring one another and talking through technical problems. Pinault is not the only software engineer to see the value in paired programming, particularly as COVID-19 has relegated developers to coding over video calls.
What is Remote Pair Programming?
Rod Olsen, head of engineering at Ripl, said paired programming is a key tenet of the Seattle social media company’s agile development style, which has a goal of continuously shipping and iterating on features based on customer feedback. A few of the company’s 10 engineers paired remotely before the coronavirus pandemic sent everyone home, but now all are partnered virtually. As for the company’s feature deployment roadmap? Olsen said it is slightly ahead of schedule.
“We’ve been remote pairing for a couple of weeks now and our velocity has been increasing,” Olsen said.
Opportunity awaits those who can deal with the distractions, latency and the lack of non-verbal cues remote paired programming brings, said Kyle Wenholz, software engineering manager at Karat. He said virtual pairing puts everyone on an equal footing.
“It’s a great mentorship opportunity, it’s a great problem-solving opportunity and it kind of forces everyone to be more intentional,” Wenholz said. “I think it kind of levels the playing field a little bit.”
Let developers decide when they need help
Over the past six years, Karat has conducted more than 60,000 remote technical interviews for tech companies. But the Seattle company only recently instituted a remote paired programming policy for its own 14 engineers, Wenholz said.
Karat adheres to an ad hoc process for assigning remote development pairs. During their daily stand-up, Wenholz asks engineers about their goals for today and tomorrow, and if anything is preventing them from achieving their aim. It’s then, he said, that developers speak up if they want to be paired.
“That’s always the question that leads to, ‘How can we help each other out? Do we need to do a pair programming session?’” Wenholz said.
At Outreach, all new developers spend their first few months partnered with a senior software engineer. Once they graduate on to individual contributorship, junior engineers then can decide when to reach out about pairing, Pinault said.
“I find pairing often is also helping you to keep your sanity,” he said.
Pinault believes that a second set of eyes often catches minor errors the initial developer may have missed. Paired programming remotely also offers flexibility, can show developers another way of working through a problem and results in faster feature development, he said. Particularly now, as the team has gone totally remote, paired programming keeps coworkers’ ties strong, Pinault said.
“The more you have empathy, the more you know people, the more your mind is open and flexible in terms of receiving feedback, the easier it becomes to do pairing,” Pinault said. “We become closer and our pairing becomes even more efficient.”
Tools for keeping connected while coding apart
Pre-pandemic, remote pairs at Ripl continuously streamed their video chats over a public monitor at the office, so anyone could see what they were working on and talk through problems. David Redenbaugh, chief architect at Ripl, credited these same Google Hangouts for recently increasing the company’s productivity.
When engineers paired in the office, each used a separate laptop, which sometimes led to them getting distracted, Redenbaugh said. At home, however, he said the physical distance leads to more intentional communication and makes it easier to multitask, with one developer looking up documentation or checking in on another case that’s coming up as the other codes. Redenbaugh said the team keeps all its Google Hangout links public, so anyone can pop in to anyone’s discussion at any time.
“It’s definitely made us more mindful of how we do meetings, and how we communicate,” Redenbaugh said.
In the office, Ripl engineers used a literal whiteboard to talk through ideas. Now that they’re pairing remotely, the group uses a color-coded Google spreadsheet to whiteboard proposed feature plans and organize what they’re shipping for the day.
Figuring out how to structure their whiteboard sessions has been the most challenging part of going totally remote at Outreach, Pinault said.
His team uses Zoom for video conferencing, Confluence or Google Docs to collaborate on design documents and, occasionally, Visual Studio Code to share code.
The company’s whiteboard sessions are now done through a mix of Zoom and Visual Studio, with engineers choosing which tool to use based on the complexity of the discussion. Engineers use Zoom for simple screen sharing of demos or code, but use Visual Studio for deeper code collaborations.
“I feel like if people use Visual Studio it’s even easier because I can literally be in the code and so I can start pointing, ‘Let’s try this, let’s try that,’” Pinault said.
Related: See Remote Software Engineer Jobs from Top Tech Companies
To drive, or to navigate?
A standard rule for paired programming is that junior developers act as drivers so they get the experience of writing the code. Senior developers then serve as the navigators who oversee and think strategically about their partner’s feature progress.
But, as with everything, there’s always an exception, Wenholz said.
When a more senior engineer is driving, they need to be careful not to just start coding without getting their partner’s input, Wenholz said. If the senior engineer is acting as the navigator, they need to remember not to just tell the junior driver what to do.
“It’s really important to create that back-and-forth collaboration, while inserting moments of teaching,” Wenholz said.
Talking out loud lets people know what you’re thinking
Drivers also shouldn’t assume navigators understand all the development moves they’re making, Redenbaugh said. “Talk about it and listen to each other. People have lots of different circumstances, and you need to kind of meet them where they’re at.”
Paired programming remotely means that hand gestures or strong sighs can be hard to follow, even during over a video call, Redenbaugh said. Narrating the choices you make helps the navigator follow along, Redenbaugh said, and focus further on future issues.
Sticking to building one feature at a time also helps break tasks into easy-to-consume pieces, he said.
“Focus on what is the part that you’re trying to get better at, and what are some ways that you can try to do that, and try small, small steps,” Redenbaugh said. “You don’t need to solve all the problems at once and, in fact, that probably will actually make it harder to do.”
If a driver is not talking through the steps they’re making, Redenbaugh recommended navigators ask inquisitive questions, like why they made a specific coding decision. Wenholz said communication between the two has to be constant, otherwise the navigator might get distracted.
He recommended partners frequently check in with one another about their progress, and keep their video and chat screens open.
“Just show up ready to work and be respectful of that time with that other person,” Wenholz said.
Regular team meetings keep feature production on track
Ripl holds three 15-minute team meetings every day.
The development team is close, but the meetings are as much for work as they are for camaraderie. Meeting frequently keeps the team on track and allows engineers to immediately react to customer issues and other breaking priorities, Olsen said. It also offers new opportunities for developers to request someone to work alongside.
“We just talk about what did we do yesterday, what are we working on today, how do the boards look, and who’s gonna pair up in the next session and what are they gonna work on?” Olsen said.
‘Like correcting somebody’s spelling when they’re writing this Magnum Opus’
At Karat, most developers like to work around test cases, Wenholz said.
This makes it easy to interrupt their workflow — engineers develop a test case, write code to satisfy the experiment and the test case serves as the point of no return. If the feature works in the test case, it’s a go. If it doesn’t, it’s back to the computer screen to update the code.
Unless his partner is about to introduce a major bug to the system, Wenholz said he generally waits to interrupt an engineer until one of the frequent checkpoints. He said working remotely actually lends itself to more thoughtful interruptions — in-person, it’s too easy to tap your fingers without thinking. Keeping an eye on someone virtually, in contrast, forces pairs to be more thoughtful about when and how they interrupt their partner’s work.
“It's like correcting somebody’s spelling when they’re writing this magnum opus,” Wenholz said. “You want to avoid picking things apart when it just doesn’t matter.”
Third parties are key to resolving disagreements
The end of an argument depends on the beginning of a conversation.
Pinault said he offers feedback as suggestions, gently delivering input along the lines of “let’s try this.” He tries to remember that everyone has a different development style, and that engineers have a right to express themselves as code.
But, if an individual is unwilling to budge, Pinault said he offers to put their feature up as a pull request to be reviewed by another developer. If the pull request is blocked, he notes that the developer will likely miss their deadline for turning in their feature.
“So you’re punishing yourself by not being willing to be receptive,” he said.
Olsen said differing opinions on how to move forward with a feature happen daily at Ripl.
If a pair can’t decide how to move forward on a feature, Olsen said the two then take the issue up to their development leads and discuss how to move forward. Olsen said dev leads try to find a compromise between the two solutions, highlighting the benefits of both and having the group talk over the consequences of each proposal.
In these instances, he said it’s important employees are aligned under a shared set of values for the company.
“You definitely have to make sure that people have the same kind of belief systems about how to do stuff,” Olsen said. “It’s going to be very hard if they don’t come in with an open mind on how they will work together. There’s a lot of give and take.”
