While many people see software development as a solo adventure, there are actually a lot of benefits to developing in pairings or teams. Most team leads who are pro-pairing will, of course, praise its ability to create higher-quality products, but there’s a lot more to pairing than that.

Pairing won’t just transform your product. It’ll also work its magic on your entire team, creating an office full of not just employees, but friends who value each other’s contribution to a product and are pleased to come to the office every day and produce their best work.

However, even if you’re not ready to take the full plunge on pairing, it’s possible that you could implement some voluntary teamwork sessions to get most of the benefits of pairing for development teams that may be reluctant to work in pairs. Here are some key ways that software development pairing can help your team.

Developer pairs are often more productive

aerial photography of people on open area
Photo by John Simitopoulos / Unsplash

When you work on a goal alone, it’s up to you to keep everything on track. While most people would likely tell you otherwise, most people do not have perfect discipline. Working alone can cause you to drift away from your goals via procrastination, and having a partner is one of the best ways to keep yourself accountable throughout the day.

Having a teammate has a profound psychological effect because it means that you’re not just letting down yourself, but also your partner. It’s why so many people find that having a diet or exercise buddy helps them with their health, and this ethos can be expanded to nearly every area of life, including the workplace.

It’s not just a guilt trip based strategy though! Having a teammate can actually be a relief to many people. Developing code is more stressful than most people realize, especially with release deadlines looming. Pairing up with a partner who can help you out when things get tough can relieve a lot of workplace stress when a developer knows that they aren’t alone. A good team can overcome obstacles that a single developer might struggle with, and they’ll likely be able to do it with a lot less weight on their shoulders by bearing the burden together.

“I recommend pair programming in different situations. We use it if someone encounters a more complex task or bug to get rid of it more effectively instead of being stuck. And the two persons will know how it was solved and therefore have that experience next time and therefore learned from that situation.” - Peter Krogh

Being paired with a friend can also make work more fun, and the increase in happiness that this brings can help to combat burnout and make your team more productive than they might be on their own because even monumental tasks seem less strenuous when they’re shared.

Pairing can bring higher-quality coding to your product

When you’re writing code by yourself there’s a slight tendency to be sloppy about it. As long as you know what’s going on in the code then who cares if anyone else understands it, right? This approach obviously doesn’t work in a team setting, and when more than one person is working on the code in question, that means that your developers will need to communicate with their team members about any changes, making them more accountable for sloppy implementation and not adhering to established standards.

Plus, if everyone understands every aspect of the code, it’s much easier to cover for a teammate who needs to be out of work for an emergency or vacation. If your team spends all of their time trying to decipher a cowboy coder’s work, then your productivity will be down the drain until your missing developer returns. Paired settings help to offset this behavior.

However, pairing also creates a great team environment where developers can bounce ideas off one another. Collaborations are not only fun, but they can also lead to awesome concepts that a single developer might never have thought of on their own. This can lead to better features for your product, smarter implementations, and smoother user experiences.

“You can discuss better strategies. This is better than keeping the problem hidden all day without sharing it with others”. - Sam Harris

Pairing is also a good way to stop bad ideas before they get too far into the development process, saving your team from many hours of wasted manpower and money. While an idea might look good on paper, bouncing it around between even just one other person can quickly unravel the plan, revealing any flaws, thus making collaborating an invaluable tool in producing high-quality software products.

Team culture is greatly improved by pairing

four people watching on white MacBook on top of glass-top table
Photo by Mimi Thian / Unsplash

If a developer is used to working alone, then it’s very easy for them to start coming in to work with blinders on, focusing only on their job and ignoring everything else that’s going on. While that person could be an excellent employee who does their work flawlessly, this can still create issues when it comes to their work. Software development is a team effort and not being able to see the big picture can leave obvious weak points in the finished product.

Developers who pair off with teammates could find that they may actually gain better insight into the project by working with others. This could help them to find better context for their own work, allowing them to create a perfect fit when what they have created is used in conjunction with the work of their team members, greatly improving the end product.

By instituting random pairings, you would give every member of the team time to work with other team members, strengthening team bonds and putting those people in the shoes of others. While there will always be workplace disagreeances, you may find that people whose personalities seem to clash before may now have a newfound appreciation for those teammates and the invaluable skills that they bring to the project once getting to know them a little bit better.

“Pair Programming as most other techniques from XP don’t make you go fast, they make you go smooth at a steady pace for a long time. They give you a good feeling when you do your work as you are not alone and every corner of your application feels familiar.” - Maxim Zaks

While it’s easy to fantasize about this fairy tale scenario, the reality is that not everyone will like each other, and as a team lead, you might need to intervene to see exactly what the problem is. A good mediator could put out any fires, and it’s possible that everyone will be able to settle their differences after a while but expect at least a little friction for the time being.

You should also expect that while your developers may work together for the sake of the team, this doesn’t mean that they’re going to be best friends. In these cases, pairing them with partners they can agree with might be a better solution. While forcing them to get along might seem the most beneficial for the team, this is likely to only result in resentment and poor performance. Remember that just because you can pair everyone it doesn’t necessarily mean that you should. Team leads should take the time to evaluate every situation and all of their developers as individuals.

Pairing works great for onboarding new developers

Pairing can be a great way to make new hires feel welcome and to help in the onboarding process. A newbie developer is likely feeling anxious about their new work environment, and that can add a lot of stress to their plate. Getting to work with their new teammates can help to relieve this worry, and they’ll also get hands-on help in getting started.

“Every engineering new hire is officially matched up with a more senior engineer who becomes that person's mentor.  [1] The mentoring relationship officially lasts two months (three months -- the typical internship length -- for interns), but mentors and mentees can (and many do) continue to keep meeting if they find the mentoring relationship helpful.” - Edmond Lau

While a new hire may be reluctant to ask for help, even if they desperately need it, this process is much easier when you’re working directly with someone. Breaking the ice with casual team pairings also makes it easier for a senior developer to check up on them without making them feel their work is being harshly scrutinized and allows for gentle corrections to adhere to company procedures.

This includes instilling in them the importance of using proper coding standards that their teammates can work with, and ushering them away from any bad habits they might have taken on that don’t translate well to a team environment if they are accustomed to working as a solo developer.

Pairing can help with mental health

Many people see software development as this lonely grind where developers hide away in their cubicles or work on projects at home in their pajamas. While for many this sounds great, there is a harsh reality that comes with this setting: loneliness.

While working by yourself can sometimes be rewarding, if you were to poll many solo workers or stay-at-home programmers, then you might actually find that they miss the camaraderie that comes with office culture. Being part of a team can be great for improving moods and mental health, and happy developers put out better work.

When you pair developers, they gain this benefit by having someone to communicate with and vent to. While this seems like a small detail, it’s not to be overlooked, as it can greatly improve the work environment, not only making the workday more successful but increasing the morale of the development staff.

Having a good team environment is what makes software development less like a job and more like a family. Developers who have a team that they care for and rely on are happier to go to work and less likely to want to leave their employer, making improving team culture something that every development lead should have at the top of their to-do list.

If you decide to take on pairings in your organization, it’s important to track the success of the initiative. Many leaders take qualitative feedback from the team on how new processes are working, and will sometimes look at rudimentary metrics such as lines of code written. For advanced teams that really want to understand the impact of new process changes, there are analytics systems specifically for software engineering teams. These show how different pairs working together produces different results and work patterns, or how as a whole, or as a test team, this change impacts pull requests, output and churn.

Gitalytics is an example of an analytics system that can help you quantify impact, that uses Git and other data to show these changes. If you’d like to learn more, visit us at http://gitalytics.com.