Four weeks working in pair programming

Pair programming is a technique that might help you to reduce the bottleneck that a Pull Request represents for your team at the time of reviewing the code.

I had a problem: Code reviews take a lot of time. Talking to some peers in the industry and looking into how other companies overcame this problem, I found that the real problem might be in the Pull Request created to review the code, instead of the Code Review itself.

One of the options is to work in Pair Programming. Citing the State of DevOps Report 2023.

Pair programming is a practice that can reduce your code review time regardless of your current architecture and integration practices.

In today’s issue, I want to share my experience with Pair Programming after 4 weeks of using it.

Two software engineers working in pair programming as Bob Esponja characters - by DALL-E 3

The Challenges

The first challenge was finding the time for Pair Programming. My calendar is very challenging sometimes and having a 1 hour blocked to focus just on coding with a pair was not so easy. What usually happened was that I had some 30-minute slots between meetings. Also, I had to take into account the calendar of my pair.

The way I’ve been able to overcome this challenge was to:

• Block my calendar in advance for Pair Programming, not only for me but also for the person I want to pair.

• Dedicate the first hours of the day, which usually are not occupied by other meetings, and the chat is quiet.

Another challenge I faced was speaking the same language. I do not mean speak English, Spanish, or another, I mean how both people use different words to refer to a topic. For example, a Java class; Maybe a member of the pair says just “A Java class” but maybe the other member of the pair says “A component” and both are referring to the same thing.

I’m not embarrassed to say that the solution for me was just to get used to the words of the other person. At some point, the cognitive load is reduced because we start using the other one’s words.

Explaining with your voice what you plan to code is definitely another challenge. Let your brain just “talk” inside is easy but verbalizing it could be much more difficult if you are not used to explaining what you are coding.

In my case, I was a bit rusty at the beginning, but I was able to overcome it. What I did was to take some seconds before starting to code and also I spoke to my pair about what I was planning to do. Like a lecture. This helps your pair to not get lost and also provides feedback on the fly, avoiding tipping code that you would have to refactor later.

One experiment I did during this time was to use the feature provided by IntelliJ named “code with me“. In a nutshell, it’s a feature that permits you to write code with more people in a collaborative way over your IntelliJ IDE. The setup is really easy and the code speed by your pair is quite fast. You can see the cursor of your pair and both can code at the same time. I’m not using it all the time, I frequently open a Zoom call and share my screen, but this is an interesting alternative.

The Benefits

Did the code reviews become fast? Absolutely yes. The review is done on the fly at the time of writing the code. Both the person who drives the session or acts as the compass provides immediate feedback about how to improve the code, refactor, and so on. Remember: The main goal of code reviews is about code quality.

The truth is that, in this case, the code review is between 2 persons (the pair), and not across all members of the team. Depending on the maturity of your team this might be an issue. You don’t want to create silos within your team, so you have to ensure that the changes you made in the code, in pairing, are known by the rest of the team members (at least at high-level). To ensure this broader shared knowledge you always can add your team members to the Pull Request, even though it will be merged quickly because the code review already happened.

Another benefit I can see in Pair Programming is that you do not get stuck so often in some parts of the code because you lack knowledge. For example, maybe you don’t know how to set up a Kubernetes watcher in Kotlin but your pair does, and the other way around maybe you know how to set up all Gradle + Jacoco configurations when your pair does not know. Once again, you move faster and solid in pairing.

The last benefit I see is the quality and maintainability of the code. Maybe you do a classic loop but your pair knows how to do it in a Java XX version. More importantly, in my experience, working in pairs tends to bring out the best in you in terms of software engineering, like being strict with TDD, applying SOLID principles, and more, having a fine-tuned piece of code. Your future self will thank you.

Conclusions

I see Pair Programming as a great opportunity to speed up the delivery of the code and ensure the transfer of knowledge. The main challenge is to try to find the time for it, moreover when your role implies attending multiple meetings along the day or content switching. I strongly recommend starting with this practice. It will take some time to get used to it, but it will pay off.

I would love to hear about your experiences working in Pair Programming and also your techniques and strategies to speed up the delivery of your code!