Thoughts on Pair Programming

My team recently had an acitivity were we separately read this article: https://martinfowler.com/articles/on-pair-programming.html. We then had a meeting where we shared reflections and thoughts on this topic. The article covers many aspects and provides some real hands-on tips for teams and individuals. This is a summary of the article with focus on what me and my team thought were the highlights. We have been doing pair and mob programming for quite some time without some formal setup. This article made us come up with a list of things we wanted to start practicing.

Benefits of Pair Programming

• Sharing knowledge
• Keep focus
• Forces discussions
• Code-review on the go
• Collective ownership
• Great for on-boarding new colleagues

Challenges with Pair Programming

• Can be exhausting
• Different skill levels
• No time for yourself
• Requires vulnerability
• Interruptions by meeting

List of actions our team will start practicing more

• The driver thinks out loud more than before
• We will use a 25 minutes timer
• We will schedule time for coding hours in our calendars.
• We will start using the 5 second rule to avoid unnecessary interruptions
• We will start with mini retros after each day or ticket
• Break out to separate sessions to do research on your own

Summary and reflections

So you have decided to read more than the TL;DR. How nice! Here I will summaries some topic from the original article together with some quotes and my thoughts and reflections on those. To get a complete understanding of the concepts I’m referring to I really recommend you to read the article. This is a quick summary of some of the topics it covers.

The concept of Pair Programming

Pair programming is built upon two different roles. The driver and the navigator. The purpose of this is to have two different perspectives on the code. The driver is the one typing and focuses on the tiny goals at hand. The driver have a more tactical mindset. The navigator is an observer that takes notes, reviews the code being written and shares thoughts. The navigator have a more strategic mindset. When starting a session you usually set a timer. Read more about that in the next section.

Time Management

You should plan your work and set a timer for breaks and when to switch roles. They suggest to use the Pomodoro technique. Pomodoro means tomato in italian. The history behind it comes from an italian named Francesco Cirillo that used a kitchen timer in the shape of a tomato. He used to set the timer to 25 minutes and each interval is known as a pomodoro. You can read more about the technique here: https://francescocirillo.com/pages/pomodoro-technique.

This gives a 25 minutes long sessions to focus on one thing and without interruptions. After the pomodoro you can take a short break to get some coffee or water and then switch roles and start a new session.

Plan the day

During the start of the day, for example during daily stand up you should decide a plan for the day. Agree on hours to pair during the day and sync with everyone’s calendar. If one of you must leave early or have other meetings, make sure the other person have work to do in the mean time.

Remote session

Pair programming remote is more relevant than ever. This requires some additional setup than working together at an office. It’s recommended to share a session where both of you can write at the same time. Which is easy to do with for example Visual Studio Code’s LiveShare plugin. Pair programming remote have some other benefits like it’s easier to focus and not get distracted by things in the office.

Things to avoid

Avoid reading emails or use phone. Might come across as disrespectful. Be transparent and let the other person know what you are doing. If you must take a call or answer a message, maybe the both of you can take a short break instead.

Micro-management. Apply 5 second rule before saying anything. This means that you as a navigator don’t immediately point out errors. Instead write a note to remember and take it up later. You might interrupt the drivers thinking process. Wait at least 5 seconds before commenting on minor things.

Pairing 8 hours a day

“When working solo, we quite naturally take time to dig into a topic or learn when we need to. But that can feel like an interruption in pairing. So how can you take that alone and learning time when needed?”

Pair programming can be really exhausting. Make sure you don’t do it 100% of the time. Leave some time for other things. Especially planned alone time. Most people need time on their own during the day to catch up with other things. To reflect, read up on something or just make a phone call. Make sure you have time planned for this during the day.

“Working so closely with another person for long stretches of time is intense. You need to communicate constantly and it requires empathy and interpersonal skills.”

Challenges with Pair Programming

“Pairing has a lot of benefits for programmers who are just starting out, because it is an opportunity to learn relatively quickly from a more experienced member of the team. However, junior programmers can also experience a loss of confidence in their own abilities when pairing. “Could I really do this without somebody looking over my shoulder?

There are a few ways to counteract this. One is to let junior programmers work by themselves from time to time, with a mentor who regularly checks in and does some code review. Another way is letting the more junior programmers on the team pair with each other.”

I think this text brings up many interesting aspects. That pair programming is a good approach for junior developers to learn from more experienced developers. But it needs to be done with caution. The junior developer needs to feel confident in what is happening and to feel ready when it’s their turn to try. This requires psychological safety. Which means that there is no you feel comfortable in not knowing things and not being afraid to ask questions. You need to be able to say that you do not understand something or feel insecure about certain topics. This is really important. Not only in pair programming but in team development in general. Pairing requires vulnerability.

The article also suggest that the junior developer should spend some time on their own with a mentor checking in regularly. Or going with a third option to pair with another junior developer. I think a mix of those three is a good approach. You need some time alone where you can try things out in a more experimental way and to think and do research that fits you.

Different skill levels

Another challenge the article brings up is when the two developers have very different skill levels. This requires a good understanding from both parts for it to be successful. It can be frustrating not having the same pace and you need to decide on how to work together on this. It’s easy to assume that the one with more experience knows best. That might not always be the case. Ask questions and have a discussion about things. Also the other way around. Don’t assume that the less experienced developer cannot contribute to the solution. You both see things from different perspectives.

Pair Development

The development of a feature is more than just implementing the code. It requires planning, research, exploration and documentation. These areas also benefits from pairing. To catch misunderstandings in an early stage.

The list under Research and explore was really interesting. They suggest that when implementing a feature in a technology you both are unfamiliar with, you should come up with a set of questions that requires answers to continue working. You should split up and try to answer those questions and then have a discussion together afterwards. I’ve found it quite often that you Google together and browse articles and Stack Overflow for example. I think the suggested approach is better because it requires both to take action. And to understand questions and answers needed to continue.

Closing words

“Practice feedback, improve team communication, take measures to create a psychologically safe environment.”

This can not be said enough. To be successful in pair programming, team development and as a developer you need to actively seek improvement and communicate with each other as a team. Once again I recommend you to read the article to get a deeper understanding of the benefits and challenges of pair programming. Thanks for reading.