Skip to content

BLOG

Struggling With Pair Programming? 6 Tips Here

Here at Very, we believe in pair programming. But even the staunchest proponents of pair programming will admit that it is not always smooth sailing. When pairing is going well, programmers are delivering software, there are fewer bugs, and confidence in the product is high. The flip side of that coin, however, is that when pairing is not successful, it is easy for programmers to feel distracted and unproductive. To avoid unsuccessful pairing sessions, it is important to understand what causes them, and how you can avoid common pitfalls.

In this blog, I will be focusing on the Driver/Navigator strategy as we use it at Very, in a remote setting. However, many of these tips can be applied in person or in other pairing formats.

As the Navigator

As the navigator, you are responsible for keeping the session on track and helping the driver successfully get the code from your collective brains into a deliverable. But all too often, it’s easy to find your mind wandering away from the task at hand and down a search engine rabbit hole. I find that keeping my focus is one of the most difficult things I must manage as the navigator. When I’m not engaged with the code directly, my eyes will drift and my brain is sure to follow shortly after.

Avoid Distractions

The first thing I find to be a big help is to call out distractions to your pair. Having a partner to keep you accountable is why we pair! Being intentional about your environment will have positive effects on your ability to focus. To that end, always minimize the number of distractions available on your screen.

I try to have no more than three items open on my screen when I am navigating: a remote view of my partner’s screen, a text editor, and an empty browser for quickly performing searches. No company or personal chats, no email, no consoles, no other codebases. These things will distract you and make being a good navigator more difficult. I’d even recommend going so far as to disable notifications, silencing your cell phone, and creating as intentional an atmosphere as possible.

Keep the Driver Focused

Now that you are laser focused and locked in, it is your responsibility to keep the driver that way too. As the navigator, you should handle messages from other team members. If the driver receives a chat or an email from your product owner, let the driver know that you will respond. When you run into snags, tell the driver to focus on the code or tooling while you search online for solutions to the problem. If the driver starts to become distracted, even within the codebase, gently remind them to stay on task.

For example, let’s say there is a module for which you need to add a new function, but the driver notices some obsolete code in an adjacent method. Rather than getting distracted by this new problem, make a note of the issue and tell the driver to stay focused on the new method. Later, you can remind them to go back and refactor the old code. Small things like these will not only serve to keep the driver focused and engaged but will also help the navigator stay that way as well.

So, I’m Distracted. Now What?

No matter what precautions we may take, distractions may still find us. That’s okay. Try to reorient your thinking around a new part of your work. If the driver is refactoring a function, you can check for possible side effects on other modules. Maybe the current implementation is going smoothly, and you’re feeling tempted to open up some other windows. Instead, look to the next steps of your task and plot out how you can help the driver continue the smooth sailing.

If all else fails, try to re-insert yourself into the code, begin writing out the test for a new function, or write up some documentation based on the work you have been doing. Keeping your mind in the code is a great way to offset distractions and keep your mental state in alignment with that of your driver.

As the Driver

The driver’s job is execute on the plan that is formulated between the driver and navigator, turning your concepts into real production output. You are the person on the ground, operating the machinery that will result in new features or bug fixes. I’ve often found the driver role to be much easier, as the more active my hands are on the keyboard, the less easily distracted I am. However, narrowing your focus too much can be detrimental to a good pairing session. Your navigator is your partner and you should be using them.

Don’t Do Too Much

As the driver it can be easy to fall into the trap of trying to solve every problem. However it isn’t your role to be the problem solver, but rather to implement solutions that are determined by the driver/navigator team. If you identify a problem in the current strategy, bring it up, even if the solution seems obvious. It will keep the navigator more engaged and their perspective will improve the final output.

Don’t Shut Out the Navigator

One of the most difficult things to balance as the driver is total communication. You are in control of the tools, and with that power comes the responsibility of explaining how you are using them.

I find that narrating most of my decisions and actions is helpful in revealing my intentions not only to my navigator, but to myself as well. You may feel as though you are over-communicating, or you may not be comfortable providing access to your literal stream of consciousness, and that’s okay.

But remember – the decisions you make internally can always be improved or validated by a second opinion, so speak up about the actions you’re taking as much as you can. Ask questions, even if you think you know the answers. Having your navigator act almost like a second subconscious that can process ideas and problems for you asynchronously is a great advantage.

What If It’s Still Not Working?

If pair programming still isn’t working for you after trying these different methods, don’t panic! Pairing doesn’t always work in every situation. Maybe you and your partner have different schedules. Maybe the type of work that your project needs does not lend itself well to pairing. Maybe you two are fundamentally incompatible. It happens.  Don’t be afraid to stop pairing and work solo.

Pairing relationships are often elliptical, with the ratio of pairing to solo work waxing and waning as the project and environment dictates. Keep these tips in mind when you’ve decided to pair, but don’t force something that’s not working. In the end, delivering well-developed and well-tested products through agile, repeatable processes is most important.

Looking for a team of pair programming experts to help with your next IoT project? Contact us today.