Behind the success of pair programming

Let’s explore and analyze the characteristics and reasons for the success of pair programming.

Pair programming is becoming a mainstream programming style. After two years of pair programming experience, I have noticed that pair programming is really great, even magical. But sometimes, it hinders our development process. I want to explore the reasons behind this and figure out the patterns and methods that can make pair programming always play a positive role.

My Pairing Experience

I think it would be helpful for you to better evaluate the following content by first describing my own pair programming experience. I have been pair programming for almost two years, working for two different companies. One is a consulting company, where we developed client applications. The other is a startup, developing a large SaaS product. During this time, I have paired with more than 20 developers with different backgrounds, personalities, skills, experiences and cultures.

Side note: Another benefit of pair programming is that it allows me to work with a lot of great people and become friends with them.

Characteristics of effective pairing

Looking back on my past pairing experiences, many good and bad experiences seem to come back to me all of a sudden, as if it were yesterday. I summarized this into a 2*2 matrix.

Pair Programming Matrix

definition

Efficiency gap

From my observation, the most relevant and differentiating factor between two individuals when paired is the efficiency between them. These factors include - their previous experience, domain knowledge, language knowledge, etc. Another way to express efficiency is their output potential, including speed and quality. For the sake of discussion, in this article, efficient and inefficient programmers will be described as "senior developers" and "inefficient developers" respectively.

Positive

The expected advantages of pair programming between two people over working independently.

Pair programming with small efficiency gap

In my experience, pair programming with a small efficiency gap is generally better than that with a large gap. The reason may be that the developers have more commonalities and are more comfortable interacting. The points listed in the matrix are very clear. In essence, a small gap means that they can understand and respect each other better, are willing to communicate frequently, and learn and improve together. This will be a pleasant and win-win interaction.

Weak-weak pairing

My observations tell me that weak-weak pairs have more benefits than strong-strong pairs. Why? Probably because junior developers are less opinionated, less egotistical, and more focused on learning rather than insisting that they are "right".

You know the "new classmates make friends" effect? ​​Imagine you're a kid and your family moves to a strange town in the middle of a school year. If there's another kid in your class who transfers in around the same time, you're more likely to become friends because you're in the same situation. The same goes for pair programming. If you're both unfamiliar with a new application/technology/language/etc, then later on, you'll be better able to talk and work together to solve problems because you're both on equal terms.

The primary goal of pairing two junior developers should be to learn.

Strong pairing

If two senior developers are paired up for programming, it can be difficult to work together. This is because every programmer is different, with different ideas and opinions. The more experienced they are, the more they tend to stick to their own opinions, and the more arrogant they become. When one of them is too arrogant, the other can only be a "yes man".

Even worse is if both people are arrogant. They will constantly argue and refute each other, and the relationship between the two will be tense and hostile. I have seen even worse situations where the two people don't even say a word from beginning to end, which is obviously a negative effect.

A good strong pairing should be based on mutual respect. Mutual communication, debate, discussion, and planning should be carried out to create a professional level together. The strong combination leads to strong production capacity.

So, the primary goal of pairing two senior developers should be productivity.

Strong and weak pairing

This pairing arrangement often occurs when a new developer joins the company or switches to a new development environment. Pairing a senior developer with the newcomer allows the former to quickly integrate into the team. However, if the senior developer selected is not suitable, it may undermine the confidence and morale of the junior developer.

expect

First of all, leaders must understand that the purpose of personnel arrangement is to push the development process as fast as possible. Anyone with a stake in the project should also understand this, including other developers, designers, QA, etc., especially senior developers. And we should not put too much pressure on this combination of old and new.

Output will be slower because instruction is happening simultaneously with production.

guide

Senior developers should understand that their role is to mentor junior developers, not to produce rapidly.

A good mentor is one who is willing to listen and answer questions, observe, and ask leading questions.

But human nature makes it difficult for us to do this. Here are some key points:

Don't tell them what to type or do, and don't show them directly. It's undeniable that this will save a lot of trouble. But you should let them see the consequences of their mistakes, let them think about why it's wrong, and let them correct their mistakes by themselves. Allow them to ask questions, and then answer them with leading questions, let them explore on their own. If they get stuck in a dead end, lend a hand.

I remember one time I was paired with a completely new colleague to complete a task. Because the pressure was really high at that time, I chose to drag him forward mercilessly. Although I apologized frequently, it was obvious that he was in a bad mood.

A good mentor should have enough patience and confidence to actively promote the growth of junior developers instead of letting them become yes-men who follow the crowd. But in this field, there are too few such mentors. Everyone is busy completing their own things, or simply does not have the skills to teach others. The following questions may help us determine whether someone is a good mentor:

Are you willing to share your knowledge with junior developers and help them? Are you jealous of their skills or resent their opinions and insights? Are you willing to sacrifice your own comfort for the good of the team?

The primary goal of pairing senior and junior developers should be mentoring and learning.

in conclusion

As I analyzed above, every pairing situation is different, and the key is to acknowledge their differences and understand how to make them more beneficial to the team.

Happy coding!