How Pair Programming plays a role in practice

As a developer using Pair programming, my own experience is that it is not just a human code, but a technology observed by another person. The two programmers work very closely together, always talking, quickly writing down reminders about what to do, and pointing out code fragments on the screen. (One of the features of Pair programming is that if you use this method correctly, the screen will be full of greasy fingerprints at the end of the day .) Programmers use the keyboard in turn and often exchange it in this way. "No, let me show you what I mean ."

Based on his description of effective Pair Programming (and pointed out that not all implementations of Pair programming are effective ), he proposed four mechanisms to make effective Pair Programming successful.

 

Mechanism 1: Peer programmer conversation

Brian kernighan and Rob Pike suggested that the problem be explained out loud, even to plush toys. A practice John is studying is called Rubber-plant effect )". Part of the effectiveness of Pair programming is due to the continuous triggering of this effect: When a programmer gets stuck, repeated conversations will make it break through, this method is similar to a single-working programmer who speaks out his own problems.

He also discussed the greater benefits brought about by the conversation, and applied his so-called "expert programmer Theory"-as the problem requiring knowledge is solved more effectively, the paired two will know each other better.

So this may be where the theory of expert programmers works: experts are more likely to ask in-depth questions, which will play a major role in prompting stuck programmers. It seems that you only think that you are talking to an expert-or pretend-that will help the stuck programmer to come up with that deep question, and may have asked them before.

Accumulating the value of the conversation, he pointed out:

In this way, the first mechanism allows us to guess that more programmers talk about the program will be more productive, and those who raise in-depth questions from time to time will be the most productive.

Mechanism 2: pairing programmers will notice more details

"You cannot see your own mistakes", which is the principle in software development (and also in many other disciplines.

Wray associates this with the theory of modifying the blind and unintentional blind.

What we can notice depends on what we expect to see and what we unconsciously consider to be prominent. So although successful pair programmers usually focus more on the same thing, they may also notice different things.

Therefore, two people programming together are not good at the same knowledge or category: one person may point out a problem faster, and the other person may be faster on other aspects. In this way, their work efficiency depends on the speed at which they find the problem through observation. Two people are certainly better at thinking than one person. In fact, when people begin to Pair programming, one of the first discoveries is that people who do not enter code will always find spelling errors faster: "Oh, the comma is missing here."

Next, he raised a warning about pair fatigue: When two programmers pair, they will find something more and more similar to what they cannot find. In the end, the advantages of the two eyes will be lost.

Pairing fatigue makes us often rotate the pairing:

Some Programmers think that rotation is an optional part of practice, and there may be no other choice in small teams or teams where few programmers are willing to pair up. However, pairing fatigue means that their productivity will eventually decrease.

Mechanism 3: Fight against bad practices

Some people have clearly pointed out that this is an advantage of effective Pair programming because of the pressure from peers rather than poor practices.

He discussed examples of "encoding and correction" programming and associated it with the old * tiger * Machine gambling addiction.

This is a specific attribute of interactive programming, making it difficult for us to do the right thing. By coding and correcting the code, we modify the program at will. Every time we run the code, it is like placing the coin in the old * tiger * machine. The old * tiger * machine is the most addictive form we know. The "encoding and correction" programming brings similar unpredictable benefits, which means it is equally addictive.

Pair programming is not easily influenced by bad practices, because programmers promise to write code in a specific way and ensure that both people keep their promises. In work where people are prone to mistakes, pairing work becomes more and more popular. This will let us seriously consider that the pressure of pairing may also be our solution.

Mechanism 4: Share and comment on experts' opinions

There is a huge difference between personal productivity. At least ten factors can be divided into measurements. This usually means that the estimation of the difficulty and time is inaccurate. This is true for both good and bad programmers-you can only work closely with them to determine a person's programming capabilities.

Most programmers solve their own problems, so no one knows how good (or how bad) they are ). But in Pair programming, people continue to work together. Because they constantly exchange partners, everyone in the Team knows who is the most professional in a specific field. Out of this comparison, they will also be aware of their professional levels. In this way, we should expect that, compared with a separate programming team, through Pair programming, we can more accurately estimate the time and difficulty. From our experience, this is indeed the case.