"Individuals and interactions over processes and tools", right? Exactly right. When you're not next to each other, it's impossible to have interactions without tools. Tools have affordances. Affordances influence behavior - you will do more of what is easy in your tool. Whatever your preferred style of work is, if you're remote, you need the best possible tools to support it.

"That which does for you, also does to you."
--Gene Hughson, The Iron Law of Tools

Best-case outcome? You pair smoothly, effectively, and joyfully.

Worst-case outcome? You need a new job. --schmonz

Tool smells

- if hard to drive, and you want to...

Selection Criteria

  • Self-hosted or internet service?
  • Data lives on own machine or has to be uploaded/synced?
  • Allows everyone to drive or only the host?
  • Only two people or a mob?
  • Full-screen or terminal-only (or something in between)?
  • Includes audio?
  • Includes text chat?
  • Does your company already have this? Do they mandate this?
    • Same platform or mixed OSes?



This is high bandwidth but trivial to set up, as you don't have to deal with all kinds of firewall traversal issues.

Being at its core a screen sharing tool, you both have a mouse cursor you can each see and use to point at things while you talk to each other. Screen encoding quality can be spotty, and laggy. We've found it handy after initiating a call to have the driver in the pair initiate the screen session and surrender it when swapping. That way the person primarily keyboarding will have the best experience editing the code.

Both developers should run their screens at similar resolutions. Ideally they should be on the same platform too (Windows or Mac) due to differences in how the Windows / Command key is handled between platforms.


  • works with any IDE or editor
  • no need to learn about firewalls / tunnelling
  • heroic about absorbing VPN connect/disconnect and proxy enable/disable with barely a hiccup --schmonz


  • need an invite (since Slack took over)
  • requires reliable Internet connectivity with a decent upstream link
  • villainous about starting a share and then dying, even after everyone’s rebooted and tried again --schmonz



  • Might be really good at sharing the code-editing window (didn't evaluate it for long, because...)
  • Requires code to be uploaded to a Floobits intermediary server
  • Need a Floobits account (there's a free level)
  • Integrates with Emacs, Neovim, IntelliJ and cousins
  • Doesn’t share anything else on screen
  • Does integrate with Hangouts for audio and text chat
  • Since both of you have the same code, you can each run tests locally


  • Not a cloud IDE, syncs with your local IDE of choice
  • I'll have to try this to understand it --schmonz



  • screen


  • for voice


  • recommended by a Developer on Fire listener
  • shares one window (fine for sharing an IDE)

Chrome Remote Desktop

  • Chrome browser extension
  • Preferred by someone at Atomic Object in 2013 (blog post)
  • Said to be good under latency, etc.
  • No VPN or SSH tricks required
  • No audio (at least as of 2013)

OS X Messages

  • schmonz refuses to do family tech support any other way. Don't bother describing it to me, show me
  • Then I can drive
  • When trying this with a coworker over Jabber (Google's), accepting a share-screen request never got back to the inviter

  • voice, video, screen-sharing (maybe not guest-driving though?)

  • Terminal-only
  • can host your own server

Synergy ?


  • text chat
  • audio


  • text chat
  • audio


  • text chat
  • audio
  • host-only screen sharing (no guest driving)


  • text chat
  • audio
  • screen share (request control to interact with host's computer?)



  • for audio


  • audio
  • screensharing?

Editors Only (not screen share)

Tmux (vi/emacs)

Wemux (group tmux / mobbing)

MotePair (Atom)

Online IDEs and editors

Experience Reports

Code Craftsman Saturdays - October 2013

We did a full day workshop where we experimented with different remote pairing tools and techniques. The single most valuable takeaway was to experiment with the tools you think you want to use locally before trying doing it remotely. This shortens the try-fail loop and frustration associated with a low bandwidth experiment.

Also, always have a fall-back communication channel pre-agreed to; e.g. exchange cell phone numbers. Few things are more frustrating and wasteful than trying various communications channels not knowing the extent of a problem when someone drops off suddenly.