Pair programming can be an effective strategy for solving coding challenges, but it isn’t always the best practice. Some problems simply aren’t complex enough to require the attention of two developers. Choosing the wrong issues to tackle as a pair can lead to one or neither engineer being fully engaged, which can lead to an exercise in futility.
Keeping developers engaged is the key to effective pair programming at alcohol marketplace Drizly, Senior Software Engineer Wesley Abbey said. And open communication is a vital aspect of keeping both parties focused.
“If both developers can maintain an ongoing dialogue surrounding the task at hand, they will stay focused and pair programming becomes a more powerful tool,” Abbey said.
That tool can lead to better code and knowledge-sharing between engineers, benefitting both individual contributors and the overall team.
Jason Macauley, engineering manager at Simply Business, said paired developers should have a good relationship with each other and build an environment of emotional safety. A foundation of trust is what allows devs to think out loud and contribute to the success of an assignment.
It’s virtually impossible to produce good work without focus. A lack of engagement can create lethargy. In pair programming, apathy can be a recipe for wasted time and resources. Abbey from Drizly suggested that pair programming be used only to solve more intricate problems that will keep devs absorbed in the task and present opportunities for devs to learn from each other.
How is your team using pair programming?
We pair program on a case-by-case basis. Not everyone needs to partner on every task that needs to get done. More complex tasks are typically going to be the best candidates for pair programming. Simple problems that mostly require lots of typing don’t need to have more than one person looking at them.
The most effective pair is going to be two people who are both actively engaged.”
What are the pros and cons of pair programming?
On the surface, pair programming seems a little odd. The time and money involved in having two people working on the same problem doesn’t make sense all the time if pair programming isn’t executed effectively. If both engineers aren’t engaged, all of the benefits of pair programming will be missed. So we have no set rules for this practice. Not everyone likes to work this way and sometimes that’s fine.
However, when developers know how to recognize problems that are great to tackle as a team, pair programming works incredibly well. Code quality can be greatly improved, design decisions are enhanced and skills can be transferred well between programmers.
What makes an effective pair?
A common problem with pair programming is having one developer who does all the work while the other simply watches. The most effective pair is going to be two people who are both actively engaged in the current problem that needs to be solved. If both developers can maintain an ongoing dialogue surrounding the task at hand, they will stay focused and pair programming becomes a more powerful tool.
Different variations in programmer skills can yield different results. Sometimes having a senior developer pair with a junior helps build the junior’s skills and gives them exposure to effectual practices. However, we’ve found these benefits can only happen if both developers are actively engaged.
Developers with strong communication skills can make effective pairs. Macauley at Simply Business said engineers should be able to give (and receive) constructive feedback, which can bolster the working relationship between programmers.
How is your team using pair programming?
We consider pairing to be one tool in our toolbox. We don’t require folks to pair, but encourage pairing when working through complex problems or when bringing other engineers up to speed on unfamiliar areas within the codebase. We also leverage mob programming as another approach to accelerating teams.
Pairing requires the ability and willingness to externalize one’s thinking.”
What are the pros and cons of pair programming?
The main pro is that two heads are better than one. We also see increased throughput due to reduced code review cycle time. We do find that meetings and other non-coding activities impede our ability to pair and decelerate some of the gains we might otherwise achieve.
What makes an effective pair?
Personal skills and relationships are the key. Pairing requires the ability and willingness to externalize one’s thinking, an incredibly valuable skill that takes time to build and is dependent on emotional safety within the pair.
