Wednesday, January 19, 2011

Remote Pairing Matters

The one thing I haven't said about my time as a remote pair programmer is that remote pair programming is a brilliant idea and it matters. The reason I didn't mention it there was because that was work. This is personal development.

We improve our skills and our exposure in the world by pairing with more people. I've been a shy guy, not always jumping into the pairing sessions at conferences, and I'm the poorer for it. I could have been soaking up mojo from the greats instead of hiding out.

But remote pairing? You are not in front of a whole bunch of strangers who are potentially judging you. You're in a one-on-one situation with someone you couldn't have visited personally due to any number of travel constraints. It's just the two of you and your headphones. You can work on your code, or the other guy's code, and it doesn't matter. It can be 6am or 2am or noon on a saturday, any time your schedules just happen to coincide.

This is something I think we need to foster. We need a good system for hooking up eager remote pair partners with their peers, betters, and rising stars all over the world. Imagine how much good we could do if it were possible to pop onto some web site (a software talent agency?) and hook up with Ward Cunningham or Andy Hunt or Corey Haines for a couple of hours after dinner. It's not just name-brand acts either -- there are thousands of programmers who could teach me or learn from me in a session (maybe both). We could form up community that spans the globs, one or two time zones at a time.

The problem is that remote pairing tools all suck really bad or cost money.

Because remote pairing really matters, we need to all jump in the pool. We need to be filing reports for the likes of Yuuguu and WebEx and GoToMeeting or any other company with competence. We need a few open source projects to do screen-sharing or edit-session-sharing. Eclipse needs better sharing, though they've got an interesting start.

This is all solvable stuff. The technical side could be made to work. We just have to put ourselves into it. If we can solve the pairing technical problems, the remote partner exchange idea is just a simple python or ruby script away.

Wouldn't you enjoy jumping into someone else's code on the weekend or in the evenings. Wouldn't it be fun to put the next patch into some great OS project if you had a guide and peer to join you? Wouldn't you love to have good working relationships with hundreds of people who could recommend you for interesting jobs and projects around the country (or the world)?

Remote pairing matters, and it may be the way we all move the trade forward. It's a brilliant idea, and we need to support those who are out front, solving the big problems.


  1. I agree! I've been remote pair programming occasionally for years, and full time for 6 months. I think that remote pair programming is vastly underrated and people assume that the remote overhead is much higher than it actually is. I'm contemplating ways of engaging folks who are curious about remote pair programming, perhaps starting a remote pairing network where people can pair on each other's projects when their schedules overlap.

    You make a good point about tech: remote pair programming technology is still a hodgepodge of individual solutions. I wrote about the state of remote pair programming technology (for Mac) here:

  2. All of those options are intolerable for remore pairing.

    As someone who is really picky about tools, I tore through them all, and the only tolerable combination... that feels as snappy as Remote Desktop.... is LogMeIn Pro with the FireFox plugin. If you're not using that, it's really way more pain than it's worth

    I blogged about it here:

    And no, I don't get a kickback from LogMeIn, although I must've gotten them at least 50 accounts by now so I probably should.