"Turn" remote pair programming Combat: See how others do it.

Http://www.infoq.com/cn/news/2015/04/experiences-remote-pairing

When working remotely, pairing programming can effectively increase the interaction between developers and promote good team relationships. It not only facilitates the flow of information, but also prevents developers from distracting themselves. You can try a variety of tools to find a way to fit your long-range pairing. Pairing programming is a time-consuming and slow process, with some work that you prefer to accomplish by yourself rather than by pairing. In a distributed team, empathy and selflessness naturally emerge as a pairing.

Why do you use pair programming in remote work? In one of his blog posts, Jake McCrary mentioned several benefits of remote pairing:

The benefits of common pairing programming are also true for remote pairing processes: Letting more people understand the code, improving the quality of the code, and providing an opportunity to guide learning in this way. In addition, there is a little advantage, and this advantage in the remote mode is more obvious, that is, the remote junction pair increased social interaction.

Every time I tell someone that I'm working remotely in my apartment, one of the most common reactions is "I miss the feeling of interacting with my colleagues." While you're working remotely, you really miss interacting in the office, and pairing programming can alleviate this yearning, which can help you build and maintain good relationships with your remote colleagues.

Nickolas means, in his blog post, "Let remote work go smoothly," describes a situation in which, if every employee in each company works remotely, there are some additional benefits to implementing a pair:

People's view of the working environment in which employees work together is that through occasional conversations with others and spontaneous meetings, knowledge can be made easier to flow between organizations. Pairing can also achieve the same advantages, especially in the case of interspersed pair practice. If you often change the person you are pairing with, then you will gain knowledge from your partner, as well as share the knowledge you learned from the partners you have been pairing with in the last few weeks, especially the new team and the experienced person, who are more likely to share the value.

Pairing is also an effective way to prevent the developer from having an unconscious distracting phenomenon. When all members are in an office together, it is easier (though not easy, but at least easier) to notice whether someone is feeling frustrated, bored, frustrated, and blocking it before it spreads. While remote work alone is more prone to distraction, pairing programming is a near-perfect antidote. When you talk to another developer on Skype and share it with a text editor, it's hard to distract and focus on other jobs, and a regular rotation of pairs allows you to connect with everyone in your organization.

In Infoq's article remote work, Tom Howlett shows us how to collaborate and share information using pair programming in a way that works remotely at home:

I have been programming remote pairs for most of the day and have used screen sharing or other tools, such as Tmux. This is much better than sitting together and pairing. I've also heard that many people choose this remote pairing method even in the same office, and the advantage is that you can keep your desk and environment from being influenced by others while you are connected to others.

What happens when the team wants to gather together to study a problem or discuss the next step? We use a set of online tools to talk and share the screen, and we are still sitting in our comfortable office environment--which makes us feel good and is much easier than finding an office or a free whiteboard.

When you plan to do a remote pairing, you need to choose some tools to make the process possible. Brett Chalupa, in his blog post "Best Remote Pair programming combat environment", lists some of the requirements he considers "the ideal remote junction-to-combat environment":

• High Speed--the host and client should reduce the delay as much as possible during keyboard input, making them feel as if they were working on the same computer.
• Easy to configure-any two people should be able to complete installation and configuration work effortlessly.
• Fast startup-The time to start a pair session should not exceed two minutes.
• Use our familiar tools-in pairs, we should use our experienced editor and Shell instead of using new tools.

Based on these requirements, Fullstack has chosen to use the following tools:

• Using Tmate for terminal sharing
• Use Google Hangouts for audio calls and screen sharing
• Use Vim for text editing

McCrary also recommends that you use tools such as Tmate, Google hangout, or zoom in pairing for terminal sharing. You can also choose to standardize your development machine:

Everyone [outpace] has a computer running OS X that can be configured with a minimum 27-inch display (in most cases an Apple 27-inch monitor or a Dell machine) with a resolution of 2560x1440. Because everyone's hardware and software configuration is basically the same, we can use the built-in screen sharing feature in OS X to pair and be able to fully share the host's desktop, and this complete desktop sharing is an excellent way to mimic your partner sitting next to the seat. This approach also ensures that you can use any editor and that both sides can see browser windows of the same size (useful for testing the UI or reading references). When the network connection is in good condition, two-bit programmers have little delay in writing code. This is my preferred pairing style.

Philippe Bourgau, in his blog post, a zero-based programming expert, describes how to try out various remote pairing programming tools when a new remote colleague joins the team.

In the beginning, we tried Lync (Microsoft's chat system), with webcam, headset and screen sharing. This works fine, but the screen sharing feature of Lync does not allow for seamless remote control between Paris and Beirut (Lebanon). This is how we deal with the problem:

Through these treatments, Ahmad quickly increased productivity. We are no longer the two sub-teams focused on their tasks, but rather a distributed team that shares all the information.

• Use the "Give control" feature of Lync only in special cases: because it's too late.
• Select small commits and exchange control after each commit
• If you are unable to commit immediately, temporarily shelve the code to Perforce (you can also use Git to get the code base of the pairing partner) and exchange control

Not everyone is able to do it, or willing to do it all the time, and it makes sense to do some work without pairing. McCrary called it Solitude, and he offered the following advice on how to get some solitude:

One way to get a chance of being alone is to stagger your lunch time with your partner, so that you and your partner have a chance to get some time alone.

Other temporary moments of solitude also include meetings and interviews, and it is not uncommon for one of the pair to leave temporarily because of a meeting, an interview, or other developer help.

And when the number of members in the team is uneven, there is also the creation of solitude. If you have an odd number of team members, then you have plenty of opportunities to become a developer alone. You can try volunteering to be the lone developer, but be aware that you are not overly isolated.

Jeffry Hesse, in his blog post, "How we do remote pairing programming," shared the practical experience of remote pair programming between Michael Prescott and Chris Wilper. Here are some of the lessons they have mentioned:

Wilper: In general, I think pairing is a positive experience, and it has some obvious advantages. The most striking point is that it helps break the barriers to knowledge.

Another advantage is that it reduces the barriers to communication.

I have also found the following two major challenges in pairing experience, although they will not make me abandon the idea of pairing again, but it is worth mentioning.

First of all, in the pair of working days, every time after the end of the day's work, I will feel the extreme mental exhaustion. The reason I'm doing this boils down to the fact that we are focused on development tasks while maintaining communication with each other. Secondly, I think the final development rate of this approach will be a little bit lower than that of the respective work. Intuitively this is understandable, and this is the inevitable price we pay to break the barrier of knowledge, and in any other way it will continue to exist.

Michael: We must admit that one of the costs of this approach is that others will see you make a fool of yourself in your weak spot. Chris and I both realized that we were always unable to remember the API of the mock expectation result, which made us feel a bit hot on the face. But this approach also has a corresponding advantage, that is, your partner can always point out some tips on the use of tools, and in other ways you can not understand them (such as the IDE navigation or refactoring shortcut keys, the most useful karaf commands, etc.).

As to how to apply the remote junction to this point, I first think that this is a tear down barriers, the best way to share knowledge. Therefore, I recommend that you use this approach when dealing with a large degree of design uncertainty, inherent in complex requirements, the emergence of an unnatural nature of logic, or interacting with a complex third-party API.

Means also analyzes how the end-to-end process helps them build a distributed team and gives the team empathy and selfless spirit:

Pairing programming is a great way to recruit developers who have high EQ vendors. Developers who are willing to do all-day pairing often have a high degree of self-knowledge. They don't care about the possibility of being violated, and they can admit knowledge they don't know. They are happy to like others, and most of them are able to avoid common software developer traps, which always want to show that they look smarter than everyone else on the team.

When most of your team is a developer with a high EQ, you can naturally emerge from the team with empathy, selflessness and other outstanding traits.

View English Original: Experiences from Doing Remote pairing

"Qcon Beijing 2016" "seven weeks Seven concurrency model" author Paul Butcher, Dojo Toolkit co-founder Dylan Schiemann, Goldman Sachs Technology Division VP Lin Wen, Peak Rui Capital Technology partner Shup, LinkedIn Java performance optimization expert Zhang, Experts such as Rust contributor Zhongxiaoli will gather Qcon to share the best technology practices and more. Now buy tickets to reduce 680, 5 people buy more discount.

"Turn" remote pair programming Combat: See how others do it.