Sometimes two heads are better than one
Effective collaboration is one of the core traits of any productive engineering team. Everyone thinks differently, so having a second set of eyes on a problem can offer multiple viewpoints and approaches that you might otherwise overlook. For software engineers, the most common form of this is pair programming.
Sometimes pair programming gets a bad rap. Critics argue that putting two developers on the same task slows overall team velocity, but it saves time in the grand scheme of things. Not only does pair programming produce higher quality code, but it helps developers quickly solve problems and remove blockers. I’ve been pair programming with my colleagues a lot recently, so I’d like to share some tips for getting the most out of it.
Every pair programming session is different, but the goal is usually consistent. Most of the time, you are trying to develop a solution to some complicated problem that warrants two pairs of eyes. While some developers may prefer to get the simple stuff out of the way first, I like tackling the meat of the problem before I do anything else.
The easy parts are usually tasks I can quickly do myself or mundane chores that are more of a grind than anything else. When working with someone, I don’t want to waste their time and make them watch me write documentation for my interface or add error logging. I prefer to jump in and attack the challenges that need two people to solve.
Leave behind signals for yourself to clean up later on your own, such as comments or TODOs. Define empty method headers and classes that can be implemented later, or fill in parts with pseudocode. If you intend to run your code during the session, add a skeleton implementation that might only cover the happy path and exclude the edge cases.
Building off of the last point, I generally try to avoid nitpicking when pair programming. There is a time and a place for nits. For me, it’s usually towards the end when I go through the code that was written and get it cleaned up so I can send it for review. Insisting on near-perfect code is reasonable in the cleanup stage, but if you are still in the problem-solving phase, then nitpicking just slows things down.
As much as I love being in the driver’s seat, it’s good to change things up now and then and take the backseat role. Watching how someone else works can be just as insightful as doing it yourself. I like to observe how they approach problems and the steps they take to overcome them. Sometimes this helps me learn new techniques that I can apply to other situations.
On the flip side, try to take the reins if you are usually the observer. Sometimes you just need to feel the problem with your own hands to understand the environment and the conditions you are working with. Hands-on experience is often the most effective way to learn and build your skills. Having a partner to program with acts as a safety net to help you write good quality code and quickly move past problems and blockers.
Pair programming is a two-way street; if you only go one direction, you don’t get to see the other way, and neither does your partner. Ensure that both of you get to practice both sides of the experience, and you’ll be better off in the end for it.
Sometimes I feel like I might suffer from performance anxiety. When I’m being watched, it’s like my brain completely shuts off. I forget how to type, make tons of silly mistakes, and can’t seem to think straight. Even the thought of pair programming used to make me start sweating nervously. It took quite a bit of practice before I was comfortable with it.
Consider that your partner might be feeling this way heading into your session. Alternatively, you might be the one feeling anxious. Pair programming is supposed to be productive, not stressful. Make sure you and your partner are comfortable, and don’t be afraid to speak up if something is bothering you.
It goes without saying that you should be respectful of your coworkers. Don’t harass them for making mistakes or typing slowly. There’s nothing to gain from such behavior. Not everyone can do their best when others are watching.
This applies to all aspects of software engineering, but this is especially true for pair programming. Don’t just shoot down all of your partner’s ideas because they don’t match your own philosophies. That just defeats the purpose of working together in the first place.
If an idea actually isn’t feasible, talk through it first and explain why you don’t think it will work instead of disregarding it completely. By talking through it, you might be able to find a way to adapt it into something workable. In the worst case, it’s always worth documenting what options were considered, even if they weren’t applied in the end.
One complaint I have about pair programming is that it’s hard to find a good stopping point sometimes. In these situations, it feels like the session drags on for way too long, and I spend more time than I intended. Before starting, consider setting a hard or soft time limit just in case.
The ideal session length is personal preference, but I like to keep my sessions around 30 minutes. Usually, I’ll plan them out in advance and create a calendar event for them so I can properly incorporate them into my schedule. However, I’ll still take an ad hoc session now and then.
Agile textbooks talk about various styles of pair programming with defined roles. Common examples include driver-navigator and ping-pong styles. If you want to use one of these, that’s totally fine, but I generally don’t limit my strategy to the specifics of one of these styles. When I’m pair programming, I don’t explicitly lay out rules about roles or anything. I just do what comes naturally to my partner and me. Granted, I typically like best the classic driver-navigator style, where one person writes the code while the other lays out the ideas.
The less experienced developer should be the driver in most scenarios. Implementing the design of a senior engineer in a pair programming session is a fantastic learning experience, as it helps you absorb the idea and understand the fine points of the suggested scheme. I’ve been in situations where I would drive while a junior colleague navigated, but I would unintentionally fill both roles simultaneously, and my partner wouldn’t learn anything.
Experienced developers can benefit from paired programming as well, but from my experience, these sessions are better when the sessions are shorter and more focused. Senior engineers are usually better at taking an idea and running with it, so working together through the entire implementation isn’t always necessary.
Pair programming is a common practice at any tech job, so getting comfortable with it and learning to do it well is a great way to get an extra edge in your productivity. There are many variations of this practice, so feel free to play around with different styles and find what works best for you. The advice I chose to present here was intended to apply to any form of pair programming.
If you have any questions about my pair programming style or if you have any tips of your own, feel free to leave a reply. I hope these tips were helpful. Thanks for reading!
Want to connect?If you aren’t already, follow me on Twitter.