For the past four months, I have worked on a project in which I needed to pair program remotely with developers in other states, other countries, and other time zones.

Remote pairing feels different from pairing with someone in person: you lose the benefits of colocation for asking each other questions and reading each others’ moods and body language. That said, I have learned some practices that work better than others for pairing remotely, and I’d like to share them so that you can make your remote pairing experiences go as smoothly as possible.

1. Have a way to see your partner’s face. You can use a tool like appear.in, Google hangouts, or Skype. This gives you the opportunity to transfer some emotion across the wire. If you position the camera and video screen on a monitor beside you, the setup somewhat mimics sitting beside your pair. The setup also allows you to capture your pair’s attention, and it keeps both partners more engaged.
2. Learn your partner’s computer. Maybe you use a Mac and they have a Windows machine. You will probably be screen sharing, so it makes sense for you to learn to drive your partner’s computer. Learn the key bindings for their editor. Fin d out how to increase and decrease screen brightness and font size; when you are remoting in, these choices will affect your ability to see the screen, which your partner can see much more easily.
3. Think out loud. In general, you want to say everything you’re thinking while pairing. It helps your pair partner assist in your thinking. For remote pairing, that becomes especially critical. They cannot see or feel you there. Watching a little cursor on a screen becomes monotonous so fast. To prevent that, you need to give your pair constant context as to what you are doing.On a larger scale, in remote pairing, every interaction that might have been implicit in in-person pairing needs to become explicit. Handoffs are a good example. It is easier in person for someone to reach forward and indicate that they would like to take the keyboard. It is also easier for them to do so, as they are likely much more informed about the context of changes being made. In remote pairing, by contrast, one person tends to become the primary driver for much longer periods of time. This gets tough for the driver, who has to both drive and orate everything. More frequent handoffs are possible if the pair is explicit about it. For example, the driver can look up and say “Would you like to take the keyboard for a bit?” Frequent handoffs make remote pair programming less boring for the watcher and less exhausting for the driver.

A few don’ts of pair programming as well:

• Remote pairing is wherever, but it is not whenever. Pairing across different schedules is not effective. One person solos until the other one shows up, then the first one has to leave because there’s a three hour time difference and the other one has to solo. Add in differences in lunch times, meetings, and other commitments, and what you have is a mishmash where no one has full context on anything and everyone looks to the Slack channel to figure out what to do. Work can get done this way. But the engagement, the knowledge transfer, and the interpersonal interaction of pairing are all significantly impacted here. This sort of work environment is not ideal for defaulting to pairing.
• Network security regulations complicate the pairing  setup. Firewalls, for example, can prevent programmers in two different offices from using unapproved screen-sharing tools across their computers. This adds another barrier to the already long list of them associated with remote pairing. Defaulting to pairing is probably not a good solution for a team until and unless they will not face barriers like these. For that reason, if two teams intend to remote, security barriers should be discussed prior to making the pairing arrangement, and they should be addressed before pairing begins.

Remote pairing sacrifices the engagement of in-person pairing in favor of the space and independence of the individual pair partners. I find remote pairing to be much less effective than in-person pairing for transferring knowledge or getting to know someone. That said, sometimes it is the most convenient way for programmers to connect.