Myths and Debates: Pair Programming
Curious about pairing? Jump into this engineer Q&A all about pair programming. It's the pair-fect way to get started!
by Jessica McManus
For the uninitiated, Jason Garber, Promptworks co-founder & COO released, Practical Pair Programming in 2020 with a book apart. It’s listed as one of shopify's best app development books of 2020 and also featured on technical.ly. Pair programming or “pairing” is a staple here at Promptworks, its key elements even bleeding over onto the operations team. We reached out to our engineering team to answer some FAQs about pairing, address some myths and give their opinion on some hotly debated pairing topics. Without further ado:
How do you advise a person to bring pair programming to an organization that doesn't pair (or thinks it pairs, but doesn't really)?
Coming from orgs that almost never paired, I was really hesitant to request other people’s time when I first joined Promptworks. It wasn’t until I worked on projects with tech leads that set pairing as an expectation that I started to come around. So I think if you have people in the project who are looking out for complex/tough tasks, and who are empowered to encourage pairing on them up front or after a certain amount of effort has been made individually, that goes a really long way. ~ Jon Long
Know What It’s Best for
Don’t do pair programming for busy work or really simple stuff. It’s going to cost more and you won’t get any of the benefits that come with pair programming.
~ Ray Zane
I think the rewards of pairing are greatest towards the beginning of projects, when the setup and initial groundwork is being laid. It is helpful to come to a common understanding early on about how the software will work, and what kind of patterns should be followed. This kind of pairing pays forward and helps to support feature velocity later on.”
~ Ryan Hinkel
How can I successfully integrate this methodology and mode of practice within an enterprise? I have attempted to showcase and establish pair programming ... it was not received well. Perhaps I, initially, had bad timing.
Ease into It
I think onboarding new members either into the organization or into a new project is a perfect entry point, since that’s probably when pairing is most common in any org. If you can use some time after the initial ramp-up to work on solving a handful of problems together, that’s a great way to ease into the practice and start seeing some tangible benefits. ~ Jon Long
Identify The Right Times
If pair programming is not an accepted part of the culture where you work, try to find opportunities where it makes sense. Some good moments to do this might be when a particular team member is stuck. In this way pairing can serve to bring teammates up to speed faster in a problem space they may not be familiar with. It can leave the team in better spirits too. The alternative is often that someone takes over the work, and the original owner loses motivation and is unproductive anyway. It is often worth it for that person to get a chance to pair with someone who knows how to solve the problem. ~ Ryan Hinkel
Understand the ROI
Firstly, you can recoup much of the time. Code review is faster, both because it is more likely the reviewer has seen or worked on the code, and because there tends to be stronger agreement on software patterns. There tend to be fewer bugs to fix later on. Also, some people tend to be more efficient when working together. It is easier to get demotivated, stuck, or lost in a rabbit hole when working by yourself versus when you have someone else along for the ride. There are benefits to increasing the shared understanding of the codebase as well, especially when team members leave and new ones join the team. ~ Ryan Hinkel
Limit the Scope
You don’t need to pair program 100% of the time to reap the benefits of it. The benefit of pair programming is most obvious when you’re working on the most complicated or most mission critical parts of the system. You could choose to only pair program on those things. ~ Ray Zane
What are some tips and best practices for effective remote pair programming?
Adopt New Tools
I’m curious about this myself. From a tools perspective, Screen is a tool that lets you trade off control of each other’s screens, or lets one person annotate the screen while another types. I’ve heard good things about Tuple as well, which I think has similar features, but haven’t used it. Zoom works too, it’s just a little more tedious to describe things rather than circle them or point at them. ~ Jon Long
Adapt Your Approach
For me, remote pairing fatigue sets in quicker than it does in person, so I try to stay mindful of moments where we’re both starting to spin our wheels a bit and use that as a cue to step back and take a break. Those problems are often solved after a little distance or in the next session. Remote pairing is also more impersonal for me, and if I’m not careful I find it can magnify those little moments of impatience or frustration, and that’s exactly the opposite vibe I want the other person to receive. So I try to enter each one with a relaxed and curious mindset and not let myself forget about my pairing partner by treating it like a task to move through quickly. ~ Jon Long
If you you want to know even more about pair programming you can purchase Jason’s book through A Book Apart. Or you can contact us to see how our team can get to work pairing on a custom software solution for your business today.