A Pair is nothing new. We work on Pair. However, we often find a problem: “Two people simply sit and work together or are ordered by the leader to sit and work together, there is no improvement in work efficiency. Many people at work understand the word Pair more than what Pair is supposed to do. This article will describe in detail the details of the Pair, the main design is as follows:
- What is Pair Programming?
- Why are we doing Pair Programming?
- Pair Programming Problems (14 Frequently Asked Questions)
- Extension of Pair.
This article doesn’t cover specific code, but understanding Pair Programming can help you get a lot more done.
91 What is Pair Programming?
To start with, Pari Programming is one of the core practices of XP (Extreme Programming), which was introduced in 1999 in Parsing Extreme Programming – Embracing Change. XP’s credo is: if a practice is valuable, we make it great. With over 20 years of practice, Pair Programming has come in many forms and many tools.
Understanding of Pair Programming is divided into broad understanding and narrow understanding:
(1) Broad understanding: two Dev/BA/QA etc. sitting in front of a computer developing software;
(2) Narrow sense: Two Devs sit at a computer developing software.
After more than 20 years of Programming, we can use Pair Programming for many things, not just code.
Pair Programming form:
** (1) Keyboard/mouse type. ** If you search Pair Programming on YouTube, you will find two children sitting in front of a computer, one operating the mouse, the other operating the keyboard. I have never used this method in real work so far.
** (2) Ping-pong form. A method often used by **. For example, THE TDD process can be completed in the form of ping-Pong. A writes the test, B writes the implementation, B writes the test, and A completes the implementation. In the form of ping-pong, there will be a problem of two people grabbing the keyboard. For this, we can use the switch method to take turns and ensure that only one person can operate at one time.
(3) Navigator Driver. Pilot-driver mode, those of you who have seen a rally will notice that there will be two people in a car, one navigator and one driver. The navigator focuses on achieving the big goal, the Driver focuses on how to achieve it. For example, to turn the navigator and the driver are expected to turn, the navigator will give instructions, 200 meters ahead of the hairpin bend, downhill, the road has broken stones, the driver to control the throttle, gear, direction to turn. In this way, the two of you need to agree on a problem, and then the Driver starts writing code. The Navigator in the observation state is more active and has a better idea than the Driver. During the Pair process, Navigator should not easily interrupt Drvier’s thinking. Devier may have found some problems, but the time to deal with the problems is different, so Navigator should not speak at this time. Keep your Driver consistent. When the Navigator finds that the other party is unaware of a problem, it alerts the other party.
(4) Other forms. The Pair format is not static. The most direct way to evaluate the Pair format is the result. If you are not familiar with Pair Programming, you can try the above 2 methods. Once you are familiar with Pair Programming and understand its purpose, you can improve the form and frequency for specific problems.
Note the following points during Pair Programming:
** (1) Communicate more. The purpose of communication is to reach a consensus and find a solution. First reach a consensus before action. Avoid jumping into action without thinking about it or if you don’t agree with it.
** (2) Exchange friends regularly. ** It is not recommended that the same two people always Pair in a team. The reasons will be explained in detail later. Use a mechanism to periodically exchange Pair Programming objects.
** (3) brave. Be brave enough to ask for feedback that solves problems or improves productivity. Accept feedback courageously, admit what you didn’t do well, and respond to your partner’s honest feedback.
** (4) Confirm the task list first. Tasking communication was aimed at reaching consensus, so Pair Programming needed to determine the task list before Tasking. Tasking processes were also a process of reaching consensus in addition to the process of task splitting.
** (5) Sustainable pairing. ** If you participate in the pairing, you will find that it takes a long time because the brain is very tired to pair for a long time. It is recommended that the pairing time can be maintained for 5-6 hours a day, not more than 8 hours at most.
** (6) Feedback Be brave enough to give positive feedback, even if you don’t think it’s necessary to Pair and be clear about why not.
92 Why should we do Pair Programming?
Using Pair Programming on many team projects is not just a formality, but a practice that pays off.
Here are some of the benefits of using Pair Programming:
** (1) More focused. ** A developer’s daily development time is limited and this is already an experiment, so many people improve the environment and methods to increase focus. As a result, Pair Programming can improve the ability to focus in this area.
(2) Improve the efficiency of problem solving. When two people are working on problems, they can be more open-minded and reduce the time wasted when problems get stuck. Of course, there are times when Pair Programming does not improve productivity, and that should be avoided.
** (3) Reduce errors. ** Quality is built in, the earlier errors are found, the less the repair cost.
(4) Knowledge transfer. Information is asymmetric in many scenarios. Pair Programming can eliminate information bottlenecks, especially when understanding business and technical contexts.
(5) Increase team friendship. Through Pair Progamming, colleagues in diplomatic missions can get to know each other and get familiar with each other.
The above description covers only part of the benefits. In the real world of Pair Programming, you will encounter a variety of problems. Understanding these problems and solving them will lead to the benefits described above.
93 Frequently Asked Questions in Pair Programming (14 FaQs)
(1) “I used to write it myself, but now I have to explain it to another person, what a waste of time”, “I don’t understand, I just like writing code, don’t force me.”
From a personal point of view, the above two statements make sense.
But “design and programming are human activities, and to forget that is to lose everything.”
What this means is that software development is now a team thing, not a single person’s problem. Many teams have noticed this point, without team members working separately, the team will be efficient, if there is a problem, multiple people can solve the bottleneck of many teams. For example, continuous integration teams often have a rule of “red no overnight”, and problems encountered during continuous integration should be immediately addressed and solved collectively.
Therefore, the above questions are only expressed from a personal point of view, not necessarily the real appeal of the team. Being clear about the team’s purpose and considering the context at the time helps us to make clearer judgments and decisions.
(2) Isn’t it a waste of time for two people to sit in front of a computer?
We don’t worry about intuition, we worry about not testing it, whether it’s in startups or continuous improvement. So it’s normal to feel worried about wasting one’s time, but whether that’s actually the case depends on a lot of factors.
No Pair doesn’t mean you don’t waste time.
You can implement pairs over a period of time and count whether the team’s output has increased over time. The Pair focuses on the long-term benefits of the team, which can also bring high efficiency benefits in the short term after proficient application.
(3) Is it generally recommended to configure the ability level or according to the task received?
This can be done based on the actual following, where pairs are determined by new and old colleagues. Switch Pair indicates the select Pair object.
(a) For new colleagues to come to Switch Pair, they can understand the details of the business. Switch means to replace the Pair object regularly and according to requirements.
(b) When old colleagues come to Switch Pair, they can synchronize information instantly and complement each other in dealing with problems in new fields.
(4) What if two people have different development habits?
It’s a good thing that two people have different development habits, and that they can find something useful in each other during the Pair process. If there is not much difference between the two technologies, Pair is not advocated in pure technology, because the benefits are often not large.
Only when the context and technology of a Pair are very different, you can gain more benefits after skilled application of the Pair.
(5) How to determine whether Pair Programming can be added to the Team?
A Team has a long-term plan. The first choice is to determine the purpose of the Team’s construction and decide what practices to introduce first and what practices to introduce based on the context you already know.
In addition, understand whether there is a gap in business and technology within the team. If the difference is small then the effect of introducing a Pair will not be very large. Only when there is a big gap between the Pair’s ability and business can they benefit significantly.
Consider other factors:
(a) The ability of team members to accept new things
(b) Pressure on project progress
(c) Boss acceptance
(d) Upgrading project quality
(f) Increasing project stability and avoiding the problem of single point dependence.
(6) Is it recommended for beginners and novice pairs?
Is not recommended.
Because neither of them knows how to do it. Novices are classified into service novices and technical novices. If the two problems are similar, Pair is not recommended. There are two cases where the gap is not large:
(a) Both are new to something, and neither is clear about it;
(b) Both are very familiar, and Pair is not recommended.
When the gap between the two is close, the benefits of a Pair may not be as good as working separately.
(7) What if there is no result from two people’s discussion?
The common problem of Pair is that the train of thought is not unified and there is no train of thought.
When the train of thought is not unified:
(a) You can choose to separate the time, and then summarize and compare the results of each Pair.
(b) Arbitration can also be selected. TL is generally used to make a decision. If there is no decision, (1)
When I have no ideas:
(a) Confirm whether information can be collected before Pair,
(b) Replace the Pair object to resolve the problem.
(8) What are the costs and benefits of Pair Programming?
The cost is two people’s time spent on a problem, the cost of trust.
The benefit is an increase in the actual efficiency of the team.
How to make Pair Programming work?
Identify costs and benefits. If you are new to Pair Programming, there will be a learning cost, and you will encounter many problems in the process of practice. At the same time, there may be changes (improvements) in knowledge and skills.
To make Pair Programming work, you need to know when to use Pair Programming. Here are some common judgments.
(a) There is little difference between the technical and business contexts of the two persons ———- Pair is not recommended
(b) There is a large difference between the two persons in business or technology ————– Recommended Pair
(c) both of them don’t know the Pair — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Pair is not recommended
(10) How to measure the effect of Pair Progamming?
The effect is twofold.
One is to look at changes in overall team output, rather than individual output.
Second, by looking at the actual results, you can introduce Pair Programming records and regularly count how much the team’s output has increased and how much defects have been reduced.
Even if you decide to Pair Programming for a long time, the above notes will be useful for improving team productivity.
(11) How many hours is good for pair programming?
Practices were mentioned in the introduction to Pair Programming above. 5-6 hours per day is recommended, with a maximum of 8 days. The specific time of Pair Programming depends on the project team. Pair Programming should be carried out in a continuous period of time, and a task should not be broken up by time. If it is related to time, the Pair with broken time may be inefficient.
(12) If the project is tight, will pairing reduce efficiency?
Tight projects are not long term, and there is no project without a tight schedule. Thinking is more about how to adopt what kind of practice under the premise of tight project time. Pair Progamming is a hands-on activity that does not reduce development efficiency once mastered. The point is that there is always a learning cost when you are new to Pair Programming, but just like the learning curve, the efficiency drops briefly and then returns to being more efficient than it is now. So the choice depends on whether the team should introduce a change in practice at the time, and the goal of long-term benefits.
Simply thinking that parallel efficiency is high does not make a team truly efficient. In addition, you can refer to TOC theory to understand the bottleneck method.
(13) How to introduce Pair Progamming if you don’t accept new things?
First of all, there will definitely be a cost to accept new things. If the team does not introduce new practices, it will gain short-term benefits but will be gradually close to the edge of elimination in the long run.
Try introducing Pair Programming in stages. However, it is not recommended to introduce Pair Progamming when you do not know how to do, because no one knows when the problem is often left unsolved.
(14) How to remote Pair Progamming?
When remote Pair Progamming, we can use IM video features, such as Zoom, to share the screen to work together on a problem.
At the same time, tMATE (Terminal tool) and Live Share Extension Pack (VS Code Plugin) are also adopted.
94 Extension of Pair
(1) Are these all questions about Pair Programming?
It isn’t. One thing is missing: continuous improvement. It has been more than 20 years since the introduction of Pair Programming, during which time developers have relied on their current tools, business, and methodology.
So stop and ask yourself:
(a) Does it provide the results and quality gains we expect?
(b) Is everyone happy in the team?
(c) Did you try something to make it more effective?
Through these questions, the team can reflect and improve to achieve better productivity.
(2) Pair can also be used in other scenarios
The above scenario is mainly about development, and the work Pair can also be applied in many situations, such as talent cultivation process, personnel replacement process, new employees after entry, new field problem research.
