At Stats Perform, Engineering Manager Brad Pederson said that having two employees simultaneously think about different ways to solve a problem has led to an improved set of solutions. Those solutions have enhanced business intelligence dashboards and provided clients with reliable sports data tracking metrics.
While downsides to pair programming do exist, Pederson found that after a brief adjustment period, his direct reports preferred the practice to solo coding.
“We have five teams pair as much as possible, around 95 percent of the time,” Pederson said.
The developers at Kin + Carta rely on the method as a tool for more complex projects. Technical Principal Don Johnson said that he avoids it for trivial tasks, configuration changes, spikes or problems that have already been solved. In those cases, he warns that pair programming can lead to engineer burnout, lower-quality software and disengagement.
An instance when pair programming seems particularly beneficial? Employee ramp-up.
Based on Pederson’s experience, the pros of pair programming definitely outweigh the cons. Pederson said that at Stats Perform, the technique has allowed experienced and inexperienced engineers to learn and mentor one another, resulting in rapid growth and development.
How is your team using pair programming?
We have five teams pair as much as possible, around 95 percent of the time. There are occasions when someone will do experimental work or research, which is usually more effective without a pair.
What are the pros and cons of pair programming?
The pros include continuous peer review, increased creativity, knowledge-sharing, increased code quality and rapid learning. With pair programming, there is no need for formal peer review because it’s happening constantly. Peer review is traditionally very time-consuming or not done thoroughly enough.
Pairing also leads to less knowledge residing with a single person, which not only reduces the need for documentation, but assures continuity when engineers are out of the office. Engineers always have their pair to keep them from taking shortcuts, catching mistakes and enforcing standards. As a result, we’ve seen fewer bugs, better design and more maintainable code.
Cons include co-location and scheduling conflicts. Pairs need to be in the same location to have effective communication. Remote pairing is possible, but its effectiveness is diminished. Pairs also need to work during the same hours. Lastly, it’s not for everyone. Constant communication and pairing doesn’t work with all personalities. It’s very draining at first. That said, once people have become used to the practice over a two- or three-week span, I have found that the majority do prefer pairing.
Pairing reduces the need for documentation and assures continuity when engineers are out of the office.’’
What makes an effective pair?
Regular communication is required, so being able to convey ideas effectively is important. Often, pairs have different experience and talent levels. It is crucial that everyone is patient with their pair as they learn, and that people are treated respectfully.
Pair programming teams act as a cohesive unit, as everyone contributes in a different way. There’s not much room for people to have egos on the team.
According to Kin + Carta’s website, FleXP is a software-delivery methodology that “combines the technical excellence and speed-to-release of extreme programming (XP) with the planning and predictability of scrum.” Johnson said that the company practices pair programming as part of its people-focused approach to delivery. But the method doesn’t come without its hurdles.
How is your team using pair programming?
Kin + Carta practices pair programming as a methodology for both our XP and FleXP projects as a tool to help engineers. We also use it to interview candidates to evaluate core engineering fundamentals.
What are the pros and cons of pair programming?
The biggest benefit of pair programming is simultaneous onboarding. Having close one-on-one time with a seasoned engineer significantly helps the new engineer work through the ins and outs of the project. Working through a complex problem can spark a lot of collaborative thinking, which resolves high-quality solutions with fewer defects.
Pair programming can result in engineering burnout, lower-quality software and disengaged engineers when used inappropriately. Trivial tasks, configuration changes, spikes or problems that have already been solved should be tasked to a single engineer. Pair programming should be used in conjunction with other ways of working. It is not a one-size-fits-all solution to developing software.
Pair programming should be used in conjunction with other ways of working.’’
What makes an effective pair?
To be effective, pairs should be set up situationally depending on the desired outcome. When pairing is used to onboard new engineers, a senior engineer who likes to teach or mentor is best suited with a new engineer. When a solution to a complex problem is needed, pairing two skilled engineers is best. For any pairing engagement, both parties should have strong communication skills.
