“All too often when others are talking, we’re getting ready to speak instead of listening,” said Behavioral Scientist Francesca Gino in a 2019 Harvard Business Review article about sustained collaboration.
This phenomenon is one that any tech professional is well aware of. And it can lead to miscommunication after miscommunication during teamwork-based assignments like pair programming. Lead Software Engineer Mike Tecson said that in his experience at ClubLabs, a high EQ helps engineers avoid conflict during such sessions. The company’s engineering team follows Agile principles, programming in pairs for the majority of the workday.
While pair programming is largely dependent on individual competence and buy-in, it also relies on the compatibility of the pair. When done well, Tecson said pair programming can lead to valuable knowledge transfer between teammates.
“It facilitates context-sharing among the team so that an individual person doesn’t become the single source of truth for any solution,” Tecson said.
What is Pair Programming?
Club Labs
Mike Tecson
LEAD SOFTWARE ENGINEER
How is your team using pair programming?
Engineering holds to the extreme programming (XP) philosophy, so we utilize pair programming across all teams. Pairs program together anywhere from six to seven hours a day. Because we believe this works well for our organization, we also pair program with any potential candidates.
What are the pros and cons of pair programming?
Pair programming has many benefits. It enables collaboration, which helps us get to solutions faster. It also facilitates context-sharing among the team so that an individual person doesn’t become the single source of truth for any solution. It grows the team rather than the individual. There are fewer coding mistakes, as they are caught early on. It has also proven to be a helpful practice when onboarding new team members.
The challenges of pair programming are that both pairs should be equally engaged and actively participate for the duration of the task. If one of the individuals is not engaged, it makes pairing more of a burden than a joy. You must also be comfortable programming your solution and being able to communicate it with your pair. This is a skill that not all engineers possess or care to have.
"If one of the individuals is not engaged, it makes pairing more of a burden than a joy.’’
What makes an effective pair?
An effective pair has the ability to communicate their solutions and thoughts clearly. They also know how to strike the right balance between communicating solutions, requesting feedback and driving forward with the task without becoming too chatty. An effective pair is also socially aware. They are first and foremost engineers, but they also know how to pick up on social cues that help them foster collaboration and avoid conflict.
Lastly, an effective pair takes initiative and strives to learn. They do not rely on their partner to drive solutions, but rather are looking to contribute.
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.
Stats Perform
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.
Kin + Carta
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.
