Why Is Pair Programming a Good Idea?

Software Development Jun 12, 2020

Programmers have been trying to use many different ways to improve their code quality and productivity throughout the years.

There are time management systems, such as the ‘pomodoro’ technique, or team methodologies that help build software by means of iterative processes, as Scrum, Xtreme Programming, etc; basic approach first, like silver bullet, prototyping; and the such.

In the end, we all use different techniques that help us keep our code readable, maintainable and stable. But, what about if you are trying to learn a new language or framework, or you are just joining a new project that you know nothing about? No matter if you have 10+ years experience or you are a junior programmer, you will need time to understand all this new stuff, and your first steps may be a little bit tricky.

In this post I am going to try to show you how pair programming can help get over these situations, and how powerful it can be to boost your knowledge, and your team communication too.

What is pair programming?

Pair programming has been becoming popular during the last ten years among several teams. Pair programming is a technique where two programmers work together with just one computer, and only one of them programs, while the other is just watching.

I know some of you may be thinking. Two programmers with one computer means half the productivity and two salaries. This idea could be controversial, because you could think that making one programmer just watch a screen while the other is working, means that only one is really working.

It’s not quite like that. When a couple of programmers are working on the same computer, the one who is programming is focusing in the feature they are developing, giving the other advice or ways of doing some things. Since the programmer that is not coding is focusing on the screen, he is able to see and predict little errors that the one who is coding does not realise. These details make pair programming very useful in some cases. However, it may not work for others. Let’s take a look at both scenarios.

When doing pair programming is fine

For me, there are, at least, three different situations that make pair programming a strong powerful tool, depending on the knowledge and roles of the paired programmers:

  • When one has expertise of the tool/language they are working with, and the other one is a newbie. I will name this as The God and the peasant.
  • When one has a very deep knowledge of a project and the other one is a programmer that has been introduced recently to that project. This will be Batman and Robin.
  • And last but not least, when both programmers have a similar level. Superman and Supergirl will do.

Although you might find that the first two situations are almost the same, there are a few slight dissimilarities between them that make a real difference. Let us go through all of them so we can spot similarities and changes.

The God and the peasant

This is the easiest to spot. The “peasant” just follows “God’s” guidelines because he (barely) knows anything about the tool or language they are using. Since one of the programmers has a deep knowledge about what they are doing, he is able to be the one who is coding, so the other can totally focus on learning. Moreover, he can ask questions that may be difficult to search if he barely knows the tool or language he is trying to learn.

This is very beneficial when, for example, you are in a team and you are about to integrate Docker to a project and everyone knows it except you. Do not be ashamed, sit with your partner, who is a Docker expert, and do it together so he can explain to you, step by step, how Docker works and what a docker-compose file does.

Batman and Robin

This is a common situation in companies. Batman has been beating the bad guys all this time, but Robin recently joined him and now they are a great team. Even if Robin knows how to deal with small criminals, trying to fight Joker on his own would be an absolute suicide, since he does not have Batman’s strength and knowledge of his enemy.

When a new programmer joins your team, it is important to make his introduction to a project as painless as possible. When I joined Acid Tango one year ago, I had just moved from another city to Madrid and, moreover, I was introduced to a 4-year Ruby on Rails project. It was a huge change for me, so I was a little bit lost at first.

Luckily for me, my colleague Alex sat with me and started explaining the project’s structure, technologies, tools, dependencies, etc. After that, we started to get on with some project issues together. Seeing him develop combined with all his explanations enabled me to understand most of the flows and code, far more than if I just tried to handle it by myself. In no time, I was already able to take the responsibility of small functionalities, thanks to the time he and I were initially together.

Superman and Supergirl

Finally, Superman and Supergirl. What can I say about this team? They are incredibly strong. They can both beat the trash out with no complications. And, when a huge enemy appears, they combine their strength and team up together to defeat him.

Sometimes we have problems that may be difficult to resolve, problems that one mind can not solve by itself. Sitting with a colleague and facing that feature you are stuck in together, will result in a better solution in less time than if you tried to solve on your own.

We do this pretty often at Acid Tango. When we have to build a complex functionality, two of us sit together and, while one is programming, we discuss at the same time to find an optimal solution. It saves us a lot of time as well as unnecessary Pull-Request reviews, since the solution is a common agreement from two members of the team.

When NOT to do pair programming

We just talked about the benefits this practice could give you. However, there are a few situations that make pair programming reduce your productivity and, furthermore, make this activity boring. Here are some examples, and the reasons why they are a bad situation in my opinion:

  • When the feature to build is simple. Building some CRUD API endpoints together, in a framework you all know, does not make the difference than doing it on your own. Since there is no real challenge, the person who is not programming will be bored, and will lose the focus of the feature in no time.
  • When the one who is not programming has no idea about programming or the language. This may seem evident but it actually is not. Do not try to do pair programming on a project built in React if one of you does not even know Javascript. You can not pretend to teach the project flows while building new features and, at the same time, try to teach React to a person who barely knows the basics. It would be better to let this person learn the basics first. He will be more focused on what really matters, starting from the bottom.

These are the most common situations I have seen throughout my professional career. Of course, even if you are practicing pair programming in a good way, take time to do things on your own. Every person has their own methodologies and times. Abusing this practice may cause trouble and less effectivity because, like I said, people need to do things in their on way too.

Some conclusions on pair programming

Pair programming is a great tool not only to get better solutions and productivity but also to improve your relationship with your colleagues. If you telework full-time or are in a situation that requires it, doing pair programming is a wonderful methodology to get in touch with your colleagues and strengthen your relationship. This will make your team stronger indirectly.

So, have you ever done pair programming with someone? What was the experience like? I would like you to share your thoughts and doubts of this practice in the comments section.

I hope you enjoyed this post as much as I did writing it. Thank you for taking the time to read this.

See you coding!

Jaume Moreno Cantó

King of Back-End Development