The popular conception about programming is that it's a lonely job. Movies and TV give us the image of the sole hacker, sitting in a dark room. They drink too much caffeine, and they're able to cobble together software to do anything at a moment's notice.
A programmer, Hollywood tells us, is a wizard. They live alone, they're very prickly, and you can never understand them. Reality tells us something else altogether. Programming is actually a very social job! The average programmer spends time reviewing their teammates' code and contributing to planning meetings. And for those trickiest tickets? Many developers don't turn off the lights and turn up the music. Instead, they reach out to a teammate and hop into a pair programming session.
Many programmers find pair programming an intimidating task. They're not excited about the idea that someone will watch them write code. Fortunately, that's not what's going to happen. In this post, we're going to talk about the benefits of pair programming and how good pairing sessions go. We'll also talk about some necessary skills for pair programming and especially how pair programming can work in a remote-first environment.
Why Pair Programming?
If you've never worked through a pair programming session before, this is probably your first question. Why would I want to work on a problem side by side with someone else? The answer is, sometimes you don't! Pairing up isn't the right choice for every problem. Are you tweaking some content on a login page or fixing the alignment on an image? That's probably not a task you need two people to finish.
Instead, a pairing session is best for complicated tasks. That might be designing a new API for an external product. Or maybe you're trying to fix a nasty bug. In those cases, having an extra set of eyes helps provide better code that you write faster than one person working alone. When the developers are truly skilled at pair programming, they deliver code approximately as quickly, but with fewer defects than when working alone... The benefits to this are obvious: if two programmers working together produce code three times faster, that's a huge efficiency win. As a bonus, that work often has fewer bugs and better tests. Skilled pair programmers often deliver better code faster.
Driving Versus Navigating
In any pairing session, there are two roles, and they'll be filled by each person at different times. The first role is the driver. This is the person who has their hands on the keyboard and mouse. They're the one who's actually typing out the code and controlling the windows in the UI. The other role is the navigator. The navigator's job is to think about the bigger picture surrounding the code. They'll make suggestions to the driver about where to take the code. Their job is to think about things like what parameters you'll need on that function or how to test that bit of logic you just added. They also have the added benefit of quickly identifying bugs the driver adds to the code.
As mentioned, throughout a pairing session, each member will end up working in each role at various times. There's no such thing as someone who's only a driver or only a navigator. Filling one of these roles for an extended period of time is draining on your brain, and your work's quality can decline. Instead, practice switching on and off, finding a good time for one person to drive and one to navigate, then switching off after you finish a discrete part of the code.
Remote Pair Programming
To this point, we haven't talked at all about where the pair programmers are located. You've probably been envisioning them inside an office, chairs side by side. And that's a great way for pair programming to take place. However, there's no requirement for two developers to pair together in the same room. In fact, pair programming works just as well in remote settings. I've been a remote-first developer for nearly ten years, and I find pairing just as effective over something like Zoom as I do sitting next to my teammate. Knowledge doesn't require colocation, and neither do your pair programming sessions.
The roles for pairing programmers don't change just because they're not in the same room. Neither do your goals. You’re still working on the same problems. You might be trying to write a tricky piece of code, or fix a broken test. Maybe it’s time to hop into a lengthy code review, side by side with the person who wrote it. Those goals don’t change. You're just not sitting in the same room as your teammate.
Good Pair Programming Sessions
Good pairing sessions—whether in person or remote—all start with a well-defined problem. You might need to fix a bug or design some new interaction layer. Your goal should be smaller than a Jira ticket. Pair programming shouldn't be an open-ended attempt to complete a task. Instead, you'll find that focusing on a specific outcome provides better results. When you're remote, you'll need to negotiate who's going to drive before you get started. That person will share their screen or a coding window. Next, you should walk through a quick display of where things stand. You don't want to dive in blind and work on the wrong thing.
From there, the real work begins. Often, you'll need to stop and think for just a moment. The navigator needs time to think about how to get from where the pair are to where they need to be. Then, the navigator provides a starting point and the pair are off to the races. Perhaps you need to outline some new data classes or define a function. The navigator shares what they're thinking at a high level, then the driver starts to type it out. During this time, the navigator should be paying close attention. Their job is to think about the details of what the driver is typing. Is the code clear and concise? Should you add a comment to document a decision? How will you test this work? The navigator makes suggestions to the driver about how to keep their code effective.
This process repeats itself for a little while. Like with all code development, the goal should be to define and refine, iteratively improving the code. Eventually, you'll finish the first part of your overall task. Often, that's a good time to switch roles. Pairing is a collaborative process, and each member brings benefits to the team. The code is better when each team member is flexing all their muscles.
Pairing Skills
Like all programming, pair programming is a skill. It often feels uncomfortable and awkward at first. The best way to get better is to practice. However, there are skills that you can hone on your own to get better at pair programming. Perhaps the most useful skill is thinking about the big picture when writing code. Good code is written not just to be executed, but to be read by people. The best code is automatically tested on a regular basis to prove its efficacy. When you practice writing clean, testable code, you get better at doing it. If you're writing code like that by yourself, it makes it easier to do so whether you're navigating or driving.
Another critical skill is effectively communicating your thoughts. If you're navigating and have an idea for a function, you want to describe it once. If you need to constantly talk through what you're suggesting to your driver, your velocity will plummet. Because programming is a social art, this is a skill that will serve you no matter what you're working on. Effective communication is especially critical for remote pair programming. When you're in person, you can point to the screen to easily identify something you want a driver or navigator to focus on. That's usually not true when you're working remotely. Instead, you need to effectively communicate your thoughts so that your partner grasps your meaning quickly.
Finally, good pair programmers should work on their mechanical skills. Things like typing quickly and accurately. Those aren't necessary for good pair programming, but they're a big help. If you're driving, typing the right thing the first time keeps your velocity up. If you type it quickly, that's even better.
Pair Programming Is an Investment
Whether you're in person or remote, pair programming pays dividends with better code that's written faster. There's friction when you're first starting, and it's a skill you need to invest in. It's not something people are born good at. What's more, tooling (especially in a remote setting) can feel like it's getting in the way. Understanding your tools is key to maximizing the return on your time investment.
At the minimum, you need a tool that allows for audio communication and screen sharing. Most companies meet this threshold easily these days. However, tools like CoScreen can take pairing sessions to the next level by offering an additional degree of interactivity. It simplifies things like switching between driver and navigator, breaking down the technical barriers that come with being remote.
When you invest time in pair programming, you'll find that your code comes out faster and better. What problems do you have that would be a good fit for pair programming?
Top comments (0)