Pair Programming: Team Work Makes the Dream Work

What is It?

Pair programming is an agile software development technique in which two fellow programmers pair up and work together at a workstation. Or in today’s world, a VS-Code live share. The objective is to collaborate together sharing ideas and techniques that produce stronger more robust code while also creating a learning environment for all parties involved. In fact, pair programming is not a new concept and has actually been around since the 1940's when the first computers were created. For example, Jean Bartik and Betty Snyder, some of the world’s first programmers, were stationed to operate the ENIAC computers during World War II (Connelly, 2020) and were tasked with operating these computers effectively as a team. Thus, coining the term “pair programming” before the concept of programming really even existed ( Böckeler, 2018).

“Betty Snyder and I, from the beginning, were a pair. And I believe the best programs and designs are done by pairs, because you can criticise each other, and find each other’s errors, and use the best ideas.” — Jean Bartik

What are its benefits?

Now you may be thinking to yourself, that sounds unproductive! why would anyone wanna cut their work force in half when they could have double the productivity, that’s just bad business. However, a loss of productivity is one of the biggest misconceptions about pair programming. Most people would think that by pairing people up you are effectively cutting down their productivity by 50%. Now this may be true if the hardest part about programming was typing, however many programmers are aware that this is just not the case. Programming is a long intricate process where thinking and planning takes up the bulk of your day and as a result, pairing up your developers has actually been shown to only reduce code development by 15% rather than the suggested 50%. However, what you may lose in code production you quickly gain in your codes bases integrity, quality and efficacy. For instance Böckeler (2018) explains that pair programming is well known for its boosts in knowledge sharing and its continuous integration of multiple modes of thinking such as strategic and tactical problem solving. It also forces you to focus on the task at hand while making you explain and justify your choices, leading to stronger more dynamic code that continuously reviewed on the go. Thus, resulting in fewer bugs later one. In fact, Alexandra Altvater (2017) states that it can actually lead to 15% fewer bugs than code written by solo programmers, which for big companies has the ability to lead to massive savings over time. But its not only about monetary gain, some of pair programming’s biggest assets are the potential for team building, collaboration and homogeneity of code across a company. For instance, its a well known fact that communication and team work fosters creativity. This forces individuals to change their perspectives and look at code from a new angle, enabling them to come up with different solutions that they may not have thought of on their own.

What are the drawbacks?

So why did it take nearly 50 years for this agile software development practice to resurface and become the norm in today’s tech industry? Well as Tom Howlett (2013) explained,

“To pair requires vulnerability. It means sharing all that you know and all that you don’t know. This is hard for us. Programmers are supposed to be smart, really-crazy-smart. Most people look at what we do and say “I could never do that.” It makes us feel a bit special, gives us a sense of pride and pride creates invulnerability.”

Pair programming can be nerve wracking for some, especially for junior developers or people who have little to no experience with it. It is an intense form of collaboration that can be scary for people. Your work style is personal to you and pair programming means allowing someone in to watch your every move, see every mistake you make and judge you on every VS-code shortcut you don’t know. In undesirable circumstances it can also lead to an unbalanced workflow where one person ends up watching while the more experienced or outgoing developer takes control leaving the other to feel undervalued or a sense of unbelonging. However, on the other hand it can also lead to an egotistical battle of the brains where two experienced developers take it as a chance to go head to head with one another in order to assert once dominance in the office as the more proficient coder. However, these drawbacks can often be viewed through the lens of a mismanagement perspective shedding light on the issues with the implementation of the practice than as problems with the practice itself.

Is it worth it?

Well that is entirely dependent on your situation. There is no doubt about it, pair programming is good for the industry. But the real question is, is it good for the individuals sitting beside you?

If you’re a business that prides themselves in being a collective team where learning and building strong relationships and creating a sense of community among your employees is at the top of your to-do list. Then there is no denying the immense benefits pair programming can have in building a robust, efficient code base all while creating a sense of unity among your colleagues. Although if there is one thing to keep in mind it’s that pair programming is an intense mode of collaboration that brings forth a concept of violent transparency that if left mis-managed can result in more harm than good. After All people take pride in their autonomy and the ability to work alone from time to time.

Best Practices

So if you think that pair programming would be good for you or the company you work for, here is a list of a few pair programming best practices.

1. Agree on a programming style that works best for you and your partner or the particular situation. For example, Driver and Navigator, Ping Pong, or Strong Style
2. Switch roles often and take breaks when needed to avoid burning out or becoming agitated.
3. Have a comfortable set up. Your going to be working closely with one another so respect each others boundaries and spend some time configuring your work space so that you and your colleague are comfortable.
4. There is not always a “RIGHT” Way to do things in programming, so do not micro manage and let the driver finish their train of thought. You want your partner to feel valued. Once they are finished you can discuss other solutions or show them how you may have approached the problem
5. Pair programming is about seeing code from another prospective and learning from one another so park the ego at the door. Encourage respect and don’t be too cool for encouragement.
6. Have fun! Build Relationships, and learn from one another.

Sources

If ENIAC Engineers Could Pair Program, So Can You- Shirley Connelly (2020)

The Shame of Paired Programming -Tom Howlett (2013)

To Pair or Not to Pair — Birgitta Bockeler(2018)