Programming Pair: we help each other succeed

Summary

Pair-Programming is how two developers work on just one computer, one driver, one navigator, more interesting than you imagine. Changing roles constantly helps to communicate smoothly, they work together better and faster when they do it alone.

The driver focuses on strategy – write clean code that can run. Focused navigation and strategy – how the source code fits into the general design, which test cases will "drive" the source code in the right direction and what refinements will improve the entire source code of the program.

Couples organize themselves through selecting members that best match the current task. In each pair, the role swap is done after a few hours to share vision and knowledge.

This article is taken from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly).

Pair programming: We help each other succeed

Do you want someone to sit and watch you work all day? Would you like to spend half the time just sitting silently watching others write code?

Of course not. No one likes it, especially pair programmers.

Pair programming is one of the first remarkable things about XP. Two people working on just one keyboard? Strange. But it is really amazing, and when you get used to it, there are lots of interesting things. Almost all programmers I know, after only one month getting used to pair programming, they will find it easier to pair program than do it alone.

Why need pair programming?

This chapter is named Thinking, and I introduce pair programming as the first method. That's because pair programming is to help you think better, smarter.

When you program a pair, a person writes code (the driver). The other is a navigator whose task is to ponder. When working as a navigator, sometimes you think about what the driver is typing (But don't rush to point out errors such as the lack of a semicolon, which will be annoying). Sometimes you think about what to do next and sometimes you think about how to get the part being installed to follow the overall design.

Dividing into these two roles helps the driver focus on each of the standard syntax lines without having to worry about the overall program, and helps the pilot have time to consider the program's development direction without being distraction about specific source details. Together, drivers and pilots complete their work with higher quality and faster when each person works individually.

“One study found that pair programming costs 15% more than programming alone, but is faster than making products.
and less than 15% error
[Cockburn & Williams]. However, each team is different, so the above statistics should only be used for reference.
"

Pair programming also reinforces good programming habits. XP believes that continuous testing and design improvements need a lot of self-discipline. When pairing, you will have positive pressure from your partner to perform these difficult but important tasks. You will share programming knowledge and tricks for the whole team.

You will also have more time in the programming flow – a high-productivity state that is completely focused on programming. Although you work with another person, this programming flow is still sustainable and harder to interrupt when programming alone. Because co-workers will be less bothering to see you working with others. Even if it is interrupted, the person in the pair will help solve the problem while you continue your thinking. Moreover, when you focus your attention on talking to your partner, the background noise will automatically disappear.

If all of this doesn't convince you to try pair programming, trust me, pairing is really interesting. Adding a head will help you overcome difficult problems much easier. In general, you will always be working with a smart and like-minded teammate. In addition, if your wrist aches due to too much typing, you can switch the keyboard to your teammates and continue working without losing productivity.

How to pair program?

I recommend pairing with all production source code. Many teams make frequent pairing, but not absolutely, to see that they encounter more errors if they create a menu. A good rule of thumb is to make pair programming any part you need to maintain, including test and application build code.

When you start doing one thing, ask another programmer to join. If someone suggests, feel free to agree to set up a pair. Never separate couples, create pairs naturally, flexibly, and rotate pairs during the day. Over time, a person will pair up with everyone on the team. This will help the whole team become more involved and everyone will be able to share their design knowledge and skills.

"Get the new context by rotating pairs."

When you need a fresh air, switch pairs. I often switch couples when I feel depressed or stuck. However, always keep a person who has followed the work from the beginning to help the newcomer quickly grasp the problem. There are many times, just explaining what the problem is to others will help you solve that problem.

In pair programming, even if you don't feel frustrated or stuck, changing pairs a few times a day is fine. This will make the information in the team smooth and everyone will work more effectively. Personally, I switch couples when completing a part. If I do a big part, I switch couples after every 4 hours.

When sitting in pairs, make sure you feel comfortable, not tired. Place chairs next to each other, making sure each person has enough space, and can see the screen clearly. As a driver, put the keyboard in front of you. Note: people who program in pairs tend to reach their keyboards and mice, not pull them closer (in front of them).

Pair programmers work through dialogue. Whether you are a driver or a navigator, say everything you think. Take small, continuous design steps, preferably follow the development of testing directions and talk about your assumptions, short-term goals, general direction of development, and any issues of the feature being installation or of the whole project. Ask when you feel vague about something. Discussion often helps both you and your partner understand the problem better.

"When you see a pair that seems to be low (less talk, speak smaller, or not move with other couples), it's often a sign of technical difficulties."

Are you always tired at the end of the day? Programmers often feel they have worked more and become more effective when they work alone. Practice "Energized work" to maintain working energy every day.

Drive and navigate

"With working time in pairs will become natural"

As a beginner, you will feel clumsy as a driver. You may also feel that navigators recognize ideas and problems much faster than you. Indeed, the navigator has more time to think than the driver. The situation will be reversed when you change roles, becoming a pilot. Gradually pairing becomes natural.

When navigating, you will feel like jumping in and taking a keyboard from your partner. Relax, your driver will often give opinions in both words and source code. The person will make mistakes or small errors, but give him some time to correct them. Use your mentality to think about the bigger picture. What other tests do you need to write? How does the code fit the rest of the system? Is there any duplication to remove? Can the code be clearer? Can the overall design be better?

The mission of the pilot is to help the driver work more effectively. Think about what happens next and prepare proposals. When I navigate, I usually keep an index card in front of me. Instead of interrupting the driver when I think about a problem, I write my ideas on the index card and wait until the break to discuss. At the end of my briefing, I tore the card and removed it.

Similarly, when a question arises, take a moment to look for answers while the driver is working. Some groups use more hand-held computers for this purpose. If you need more than a few minutes, find the solution with the driver. Sometimes the best way to do it is to separate, search in parallel with each other and often share what you learn. The solution framework is an effective approach.

When pairing, frequently switch roles for at least every 30 minutes, probably after a few minutes. When you navigate and find that you need to tell the driver to press certain keys, press the key yourself. If you need to take a break when driving you, give the keyboard to the navigator.

Pair programming tips

  • Work in pairs with anything you need to maintain
  • Let the pairs form more naturally than be fixed
  • Switch partners when you need a fresh air
  • Avoid pairing with the same person for more than a day
  • Sit comfortably, side by side
  • Writing code through dialogue. Let's cooperate, don't criticize
  • Drivers and pilots regularly swap roles for each other

Pair programming space

For comfortable pair programming, good work space is essential. You need plenty of space for two people to sit side by side comfortably. Typical small corner workplaces will not work. They are uncomfortable and one person has to sit behind the other, causing psychological and physical barriers that prevent collaboration.

You don't need sleek furniture to program good pairs. The best thing I've ever seen is just simple folding tables found at any good office shop. They should be about 1.8 meters long, so that two people can sit comfortably side by side, and at least 1.2 meters high. Each desk needs a powerful computer for use in programming. Each computer should have two sets of keyboard and mouse for each person in the pair.

There should be a big screen for both of you to see clearly. Some groups display on two screens the same, making it a little easier to see, but can make you just wrong the screen when discussing with each other. Others like to display a desktop on two LCD screens.

Challenges when programming pairs

Initial pairing may not be comfortable, because this way of working requires you to be more cooperative than the way you are used to doing. This is natural and usually goes away after a month or two, but you face a few challenges.

Comfortable

Keep in mind: pair programming isn't fun if you're uncomfortable. When you sit down to work, adjust the position and equipment so that you feel comfortable. Clear the garbage on your desk and make sure there is enough space for your legs and knees.

Some people (like me) need a lot of private space. Others like to sit closer. When you start pairing, discuss your personal space and your partner's needs.

Similarly, it is impossible not to mention personal hygiene. Remember that strong flavors like coffee, garlic, onions, spicy foods can lead to bad breath. To avoid problems, decide together to respect your personal habits respectfully.

Difference in qualifications

Paired programming is often a collaboration between people with similar qualifications, but sometimes an advanced, experienced programmer will pair with a person at a lower level. Instead of seeing this relationship as a student, regain the equal balance by creating opportunities for both people to study. For example, if you know you're paired with an inexperienced young programmer, you can ask that person to research a topic that no one else knows, such as the inner workings of a library. group depends on. Give everyone a chance to become an expert.

Communication style

New drivers sometimes have difficulty communicating with the pilot, they can occupy the keyboard to type their own code and lose the communication in the pair. To practice communication and role change in pair programming, try programming ping-pong pairing . When programming a pair of table tennis styles, a person A writes a test. Person B will write code to pass the test and then write a new test for A. Person A writes code to pass the test and then writes a new test. Such a process is repeated like playing ping pong.

The opposite of too little communication is too much communication, unnecessary communication. Straightforward criticisms about source code and design are very valuable, but at first we will be hard to accept. Everyone has a different sensitivity, so pay attention to how your partner accepts your comments. Try to turn the affirmative sentences (eg, "This method is too long") into a question or suggestion ("Can we make this method shorter?" Or "Should we push the code block?" Is this a new method? ”). Keep a cooperative attitude to solve the problem together.

Tools and shortcuts

Even if you are not a victim in the endless battle between vi editor and emacs, you may find it annoying to have settings in your partner's tool. Try to standardize a certain setting. Some groups even create a standard version and put it in version management. When you discuss programming standards, discuss this issue as well.

Ask and answer about pair programming

Is it wasteful to need two people to do one's job?

In pair programming, two people don't really just do one person's job. Although only one keyboard is used, programming has many tasks other than code. Ward Cunningham said, "If you don't think carefully, you might think that programming is just typing the commands of a programming language." In pair programming, one person will program and the other Think about things further, about issues that can be discovered early, and strategies.

If you need to dig deeper, [Williams] has a pair of programming studies in pairs. Remember that variations in software development make it difficult to conduct large-scale research. Sometimes the best way to know if something works well for your team is to try it.

How to convince my group or company to try pair programming?

Please test pair programming. Spend about a month for everyone to work in pairs on all product source code. Try to test a full month, even though pairing is often difficult and makes you uncomfortable in the first few weeks.

Don't just ask for permission to manage, make sure all your team members are also interested in trying pair programming. The only programmers I know who don't like pair programming after a month's trial are those forced to do it.

Do we have to pair programming all the time?

This is something your whole team should decide together. Before deciding, try pairing in all product source code (everything you need to maintain) for a month. You may find it more interesting than expected.

Despite the rules, you will still make code that you don't have to maintain (the solution framework is an example). These can benefit from personal research.

If you're bored with pair programming, see if you can make the design less repetitive.

Some tasks are so repetitive that there is no need for brainstorming. However, before giving up pair programming, see why your design requires so much repetition. It may be a sign of a design flaw. Pilot should use more time to think about improving the design and discussing it with the group.

How can I focus when there's always someone talking to me?

When navigating, if you have trouble understanding the next steps the driver is going to make, ask the driver to speak out their thoughts.

As a driver, sometimes you may find that you are distracted. Let the navigator know, they can give suggestions to help you solve the problem. Maybe, you just need a few quiet moments to gather.

"If you have trouble concentrating, try taking smaller steps."

If you lose focus continuously, you may have followed the steps too big. Use TDD (Test-Driven Development) and follow very small steps. Based on your navigator to keep track of what you need to do (tell her if you have an idea, she will write it down) and focus only on the few lines of code that need to be done to pass the test. .

If you're working on a technique that you don't fully understand, take a few minutes to work with a solution framework. You and your partner can work together or do it separately.

What to do if we are single?

The isolated programmers can do other jobs unrelated to the source code. He can research new techniques, or delve into the technology that the group is using. Or he could pair up with a customer or tester to review the program, "polish" the program or do a discovery test. Or he could also make the group's batman (in an XP group, batman is the one who handles the client's requests for help or unexpected requests, convincing them to move that unexpected request to the following segment, see add in "Iteration Planning").

Often programmers are used to taking the time to review the overall design to better understand it or think of ways to improve the unstable parts. If there is a lot of refactoring to do, an odd developer can take care of this.

If the group has only 2 or 3 people, should it be a continuous pair programming?

Even a holy man can irritate you if you just have to pair with him day in and day out. You have to decide for yourself when to program pairs and when you need time to work alone. If you are fine but your pair is getting messy, don't try too hard, take a break.

I have been pairing with a person for 3 months in a two-person project. I think it is very helpful for us to have a large office and a big table: it helps us with space to move around a stressful discharge. We also have a mini fridge with food in it.

Even when there are such comfortable conditions, I still have times to get irritated.

Perhaps it is important to help me program my partner with the same person for a long time, thanks to my partner who is very easygoing and doesn't mind the times when I get angry.

Too focused on work and forgetting to switch pairs, how to switch pairs more often?

In fact, the best time to switch pairs and get a fresh working atmosphere is when you feel stuck or "bored."

Some teams use an alarm clock to switch pairs after a predetermined time. Belshee's report shows that switching pairs after every 90 minutes gives good results. Although creating a pairing routine is great, make sure everyone wants it (Maybe someone doesn't want to switch couples and want to continue working with the old to solve the problem. about to finish, for example.

How to program remote pairs?

You can use headphones and desktop sharing software such as VNC or NetMeeting to program remote pairs. I have heard of teams that have used two computers but share the same screen together with the VoIP program. When I tried this way, I found that it was pretty bad. XP teams often sit together, so remote pairing is often not necessary.

The incredible benefits of pair programming

Once you've programmed a mature pair, you will find yourself very focused on work and working with your partner. You will be less interrupted and distracted. When someone interrupts, one person will solve the problem and the other continues the work. After the interruption, you can return to the job immediately. By the end of the day, you will feel satisfied even when tired. You enjoy working focused and friendly with your partner.

The whole group got a higher quality code. Technical debt decreases. Knowledge is within the group, helping to improve each person's level and help new members quickly integrate into the group.

Contraindicated

Pair programming requires a comfortable working environment. (Refer to the "Sit Together" designs in chapter 6). If your workspace does not allow couples to sit side by side comfortably, either change the workspace or stop pairing.

Similarly, if your team does not sit together, pair programming may be ineffective. Remote pairing is not possible when sitting together.

Another reason not to program a pair when the programmer is unable to adapt. Pair programming is a big change in programming style and you may encounter incompatibility problems. I often solve this problem by asking people to try pair programming for a month or two before making a final decision. If they still can't adapt, it's best not to apply pair programming instead of trying to force it.

Alternatives

Pair programming is a very powerful method. It reduces shortcomings, improves design quality, shares knowledge among team members, increases discipline, reduces distractions without reducing productivity. If you can't program pairs, you need an alternative method.

Official source code inspections can reduce shortcomings, improve quality, increase discipline. However, in my experience, programmers have problems including checking in their work schedules, even if they are supporting it. Pair programming is easier to do consistently, and it provides much faster feedback than scheduled censorship. If you want to use censorship where pairing is being done, add some support mechanisms to help them get implemented.

Censorship itself is not able to share knowledge as thoroughly as the collective code requires. If you can't program in pairs, consider avoiding collective ownership, at least at first.

If you still want collective code ownership, you need an alternative mechanism for sharing knowledge about the state of the underlying source code. I have established regular research teams where programmers meet daily for about 30 minutes to review and discuss design.

I do not know any method to reduce good omissions such as pair programming. However, I realized that I could not stand much trouble while I was tired. When not pairing, pay more attention to the importance of enthusiasm at work.

ITZone via tapchilaptrinh

Share the news now