In simple words, pair programming is when two developers work on the same task simultaneously. One person writes the code and the other one reviews it. In this way, they can collaborate while coding and it has many benefits such as faster development, clean code, and constant learning.
I like to compare pair programming with dancing with a partner. In dancing there is a leader – a person who leads the steps and the movement, and the follower who needs to follow and adapt their steps. In pair programming, the leader would be the person who types and the follower would be the one who gives continuous feedback. And just like in dancing, if they are in sync, the final result (the code) will be a great performance.
From my experience, many programmers, regardless of their experience level, are often skeptical about pair programming, and only a low percentage of them decide to try it. Some view it as inefficient and slow, and they fear a loss of productivity when two developers work on the same task at the same time. Also, there is the assumption that it is not interesting for both participants because it looks like only one person is in charge of coding.
All of these fears are fair and I shared them too at one point. So, I’ll describe my experience and insights gained through pair programming and why I think every developer should at least consider trying it.
My Journey with Pair Programming
The first time I heard about pair programming was some years ago when someone mentioned it during a tech meetup. It attracted my attention but the concept of two people coding together didn’t make any sense to me.
But, I wanted to improve my coding skills and learn from experienced developers so I decided to give it a shot.
I didn’t know what to expect, and I was worried about people seeing my code before it was ready. I was also afraid of getting instant feedback because giving and asking for feedback is not always the easiest thing.
So, I started pairing with a colleague who was much more experienced than I was. They were not the kind of person who would explain everything after they wrote it. So, I tried to catch up with their coding, but there was not much communication from any side. We were both inexperienced in pair programming and I was a little shy to always ask them questions. Soon I felt like I didn’t learn anything new.
Then, even though we finished the task I felt like we failed to achieve the expected goal. What I realized from this situation is that pair programming requires constant adaptation and communication. Well, to be fair, I also Googled it. My main conclusion was – not everyone is made to work in pairs so it is important to choose wisely whether you are going to do it and with whom you are going to do it.
The other person I worked with was communicative and experienced in pair programming. They were ready to take feedback and discuss it. That’s where my first steps in quality pair programming were. For me, it meant a lot because I rapidly learned new things, and I was able to see and participate in good practices. We brainstormed solutions and learned from one another each day.
It’s important to mention that it isn’t all sunshine and rainbows. Sometimes we disagreed about best practices. Also, there were times when it was hard to explain my exact thoughts to another person so they could also see the benefits of my solution for the problem. But all of these situations improved my communication skills and helped me to become a better team player.
Now, where to start?
How to Get Started
Through years of pair programming, I’ve come to one key conclusion – the key to quality pair programming is “balance”.
Who types, who reviews, who talks, who is silent, who gets to say the final word, how often do we switch roles, and how to decide what to do when you are in charge?
All of these things need to be balanced, and now I am going to explain all the important steps to ensure that.
Choose the right partner (Choose the right dance partner)
The perfect scenario for learning is that you find someone who complements your skills. But even if that is not the case, there is always a place to learn something from each other when approaching new challenges. This is also why it is a good practice to change your partners from time to time to improve knowledge transfer and team cohesion. When looking for a partner, it is important to try to find one who will be ready to adapt, be patient, and be communicative. Or best case scenario, to work with someone who is already experienced in pair programming.
Define an action plan (Define the choreography)
Before you start coding, define a small unit of work, for example, a small defect or task where you will get the feeling of how it looks to work together. Even investigating a defect with someone is a great start to see how your partner thinks. I believe it makes problem-solving faster than doing it alone.
Coordinate the roles (Coordinate the performers)
As I already mentioned, there are two roles – leader and follower. Balancing between those two will help you work faster, and better. It will also make you realize who should be the leader in which situation. Even in dance, if both partners agree, the follower is allowed to hijack the lead.
It is also important to often switch roles. When I practice it, roles are usually changed at the end of each task. But, if there is a complicated situation inside one task, it is also ok (if you both agree) to switch roles again.
Code Feedback (Form correction)
This might be the most important point on the list. You need to say your thoughts out loud. Tell your partner suggestions, ask questions, and don’t be afraid of judgment. But both of you need to be open and relaxed so the flow of thoughts goes naturally. Providing constant feedback should feel like taking a breath of fresh air.
Take breaks (Take dance breaks)
Although it is not easy to be a leader, it is not easy at all to be a follower either. You must be fully concentrated and follow every line of code. It can get a little exhausting so it is best to regularly take breaks when needed.
Do it only when applicable
And last but not least, pair programming should not be applied to every situation. There are a lot of cases when it is unnecessary to use 2 minds.
For example:
- If there is a significant skill gap it may not be as effective as it could be
- If the task is too simple or repetitive then it is also not a good idea to use pair programming
I would say that with years of practice, it becomes easier to know which tasks are good for pair programming and which are not.
The Benefits of Pair Programming
I believe pair programming is best explained through all its benefits. Here is my list of the most important ones.
Clean and quality code
Two people mean double of ideas, approaches, and thoughts. Also, I think we can all agree that the best solutions are often achieved through discussion, questions, answers, and brainstorming.
All of this helps in creating quality code – knowing that more things were considered while writing it.
Faster development
Even though it might seem counterintuitive at first, development overall gets faster when pairing. Two people represent double the experience, so there is a much bigger chance that one of them is familiar with the current requirement or problem. Which comes in handy when you don’t have the idea of how to write or solve something.
Also, it is a lot easier to catch issues and potential mistakes with two extra pairs of eyes. That saves a lot of time.
Constant learning
Learning is a big part of pair programming. As I already mentioned in the first part of this blog, through my experience in pair programming I learned a lot, and also I shared a lot.. And, the best way of learning is from practicing. You can start a discussion that can lead to a bunch of different perspectives and ideas to learn from.
Instant feedback
You can receive advice and suggestions immediately. That is a lot better than getting comments in the review after you’re already done with the task. In pair programming, the code is already reviewed while coding. This allows you to adapt and upgrade your skills and code through the process, so you don’t need to spend that extra time on review.
Larger codebase knowledge
When an explanation of the written code is needed, both developers are familiar with it. They cover a larger codebase and are fully prepared to explain the reasons behind their approaches.
So, it is harder to get in a situation where only one person knows a specific part of the code.
Final thoughts
In the beginning, it could be a little challenging to start using pair programming. But if you manage to balance the dance with your partner you will gain many benefits that can improve your coding. It could prove to be a great way to grow both as a developer and a team member.
Finally, a big shout out to my pair programming partner Mihovil Maricic!
