When I worked at "Reevoo":http://www.reevoo.com we tried to live by a mantra of "pair on all production code". Sometimes this wasn't practical (there would often be times when there was an odd number of us available) but its a rule we tried to stick to wherever possible. Obviously, now I have gone freelance, pairing isn't always a luxury I'll have - that's fine, I'm comfortable working on my own - but I've always felt that some of the best code I've ever written has been code that I have written in a pair. Fortunately, for my latest client, I am able to work with my former Reevoo colleague "James Adam":http://interblah.net who some of you may know as the author of the "Rails Engines":http://rails-engines.org/ plugin and one of the co-organisers of the "London Ruby User Group":http://lrug.org and the awesome "RubyManor conference":http://rubymanor.org/ (don't forget to "check out some of the videos":http://rubymanor.org/videos/). h3. Coding remotely From the outset, we were both agreed that we would prefer to pair on as much code as possible. The problem would be that we wouldn't always be in the same location. We've both taken up membership at "The Hub":http://the-hub.net/ which gives us a shared space to work once a week or so but the rest of the time we would both be working from home. This isn't a new problem; in fact it was one that "some":http://www.floehopper.org/ "of us":http://chrisroos.co.uk/ at Reevoo "have experience with":http://blog.floehopper.org/articles/2008/03/13/remote-pair-programming using a combination of "screen":http://en.wikipedia.org/wiki/GNU_Screen and "vim":http://www.vim.org/. However, vim isn't really my bag and I'm far more productive using my editor of choice, "Textmate":http://macromates.org. "VNC":http://www.realvnc.com/ was an obvious solution but if you're both Mac users, "iChat":http://www.apple.com/macosx/features/ichat.html offers a far more integrated solution, offering instant-messaging, voice chat and most importantly, seamless screen-sharing. iChat's built-in screen-sharing solution is fast enough to work on one person's machine whilst making it easy to switch back to your own machine when necessary. Even better is if you have a dual-screen setup (I run my MacBook connected to a Dell 20" monitor). Using this setup, I can run James' screen on my Dell, leaving my MacBook free for background tasks like email, twitter etc. It's not perfect, there are a few technical niggles; but it has worked well for us so far. h3. Remote pairing tips What has surprised me the most is just how effective this approach has been. I feel like we have been working just as effectively as if we had been sat in the same room together. We get from all of the usual benefits of pairing; the ability to bounce ideas off each-other, catch minor mistakes that the other person has missed, discuss alternative approaches to a problem and tempering another person's enthusiasm with some caution (e.g. "maybe we could do [some cool idea]...yes that would be good but do we really need to do it now?"). If I would offer some tips when using this approach, they would be: * *Make sure* you're both ready to start before you get going. Nobody likes to feel like they are being pressured into doing something. Pair-programming all day can be really draining so make sure you're both happy to begin. * *Don't hesitate* to suggest to your pair that it's time for a break. It can be good to stop for 5 minutes every now and again to make a cup of tea, catch up on some emails. * *Try to avoid* unnecessary distractions whilst in full-flow. Try to turn off other IM clients or at least set your status so people know you shouldn't be disturbed. Disable growl notifications or other annoying popups (e.g. Twitter clients). There will always be a few minutes downtime here and there which you can use to check these. Trying to do it whilst in the middle of pairing may lead to errors or missing important information and its unfair on your pair if you're not paying attention. * *Agree on who* is driving at any given time, and take it in turns, swapping periodically. James and I tend to work using the "driver writes a test, pair implements test" approach. We'll swap roles frequently but its important to know who is the main driver so you aren't always trying to type at the same time or grabbing the mouse when somebody is trying to move in the other direction. This is probably more of an issue with remote pairing than normal pairing (unless you're using multiple keyboards/mice!). * *Don't forget* that when you are connected to your pair's machine (and it's in the foreground), all of your keystrokes will be sent to the remote machine. Remote pair-programming using iChat
def my_methodhello mum
probably won't pass any tests.
* *Bonus Tip*: Quicksilver can be useful for leaving the equivalent of little notes to eachother whilst the other person is away; if you're pair has gone to make a tea/popped to the toilet and you need to leave too, just leave them a nice big message on their screen - bring up Quicksilver, hit Cmd+Period to enter text mode, write your message then hit tab and select "Large Type". They can't miss it.
If you've never paired before, or have been put off of pairing because you work remotely, give it a try; you may find you write better code than you ever did before. Does anybody else pair remotely? If so, I'd love to hear your tips.