Let’s do this thing. What is pair programming? Won’t software projects take twice as long or cost twice as much with pair programming? Do I pair with the same person every day? Who owns the code? How do performance reviews work? Do we pair on everything? What do I do if my pair goes home sick? What do I do if I can’t stand my pair? What if my pair smells bad? What if my pair smells GOOD?! I’ve given presentations at many conferences, Meetups, and companies on topics ranging from Agile team management to Android messaging frameworks. My presentations inevitably grind to a halt once I mention that I pair program: I’m peppered with questions! I’ll answer any and all questions about pair programming and remote pair programming, from the profound to the silly. I have no doubt that we will fill the allotted time with sage advice, educational anecdotes, and your own stories about pair programming.
I’m happy to help! You have a lot of options here, depending on many factors, such as your internet speed, latency between the host/remote machines, OS, etc. I’m going to assume that you’ll have high latency between you and your US pairs.
For command-line editors like emacs, you might opt for a “man in the middle” using tmux, where you and your pair connect to a shared machine in an Amazon EC2 availability zone between you. You’d both use this middleman machine and share the latency equally. Resources:
If you have fast connections, try screen sharing programs like Screen Hero, join.me, etc. The person with the fastest upload speed should host.
There are new generations of Web-based IDEs and “diff-sharing” apps that let you code in your own editor, on you machine, while collaborating with other developers. Check out https://floobits.com and https://www.nitrous.io
As for audio/video: try all the things! Skype, hangouts, Facetime… whatever works for you. Try many until you find the right ones.
Great question! The advice I’ve heard in at least two cases is to create a rate structure with pairing built in. That is, your client doesn’t get a “bonus” by having two programmer work separately, nor a “penalty” pairing: they are paying for output, at your company’s rate, however they get it.
I’m not really the expert in this area since I don’t handle rates and billing. I’m quoting mostly from http://rietta.com/ who gave a presentation at the Atlanta Ruby User Group — the entire video there is enlightening, but skip ahead to 31:00 to hear about convincing clients, billing, etc.
Reach out to them, they might have much more advice than me. Hope that helped!
People always ask me what I use for screen sharing. My answer: Screen Sharing. As in, “Screen Sharing.app,” which is built in to your mac. And guess what:
I’ll take it a step further:
Screen Sharing.app is the best screen sharing application around. You should use it if you can.
"But wait," you say, "I don’t have it on my Mac. I’ve looked in my Applications folder and it doesn’t show up in Spotlight search."
You have it! And you’re right: not only is it not where you expect it to be, but it doesn’t show up in Spotlight.
It’s here: /System/Library/Core Services/Screen Sharing.app
CMD+TABchanges the app on host machine
There are two ways:
Now that I’ve convinced you to use Screen Sharing.app to remote pair, you need to allow screen sharing connections to your Mac in order to host:
vnc://x.x.x.xaddress is the IP address on your local network people can use to connect to your machine. VPN users can likely use this address.
Remote Pair Programming turned 1 today!
There a few networks and services that help people find pairs:
From Kobra.IO’s website:
Kobra is an online code editor that allows you to collaborate with your team quickly and efficiently. After you connect to your development environment, you can see changes in your files as your team members type them. Kobra also has built in video, voice and text chat so you’re never more than a click away from your team.
Currently they are in an open beta: check them out!
Check out this excellent presentation on remote pair programming from Frank Rietta and Brandon Dees, who run Rails web development consultancy rietta.com. They presented at the October 2013 meeting of the Atlanta Ruby Users’ Group.
Slides available here: https://speakerdeck.com/rietta/why-and-how-we-remote-pair-program
Here were some of my take-aways:
One more thing: once they started fielding questions the conversation turned to pairing in general: are there times when they don’t pair? How do they convince their clients pay for pair programming? It seems like someone should do a talk that’s nothing but fielding pair programming questions…
From the book’s page on Prag Prog:
You’ve heard about pair programming’s benefits: fewer bugs, improved skills, and faster delivery. But what happens when you want to pair with someone in another city, country, or even hemisphere? With the right tools, you won’t have to relocate to refactor. In this book, you’ll learn techniques used by the most productive remote programmers in the industry to pair with anyone on the globe on any kind of project. You’ll use collaborative editors, screen sharing, secure networking, and virtualization to create a remote pairing environment that feels as if your partner is sitting right next to you.
I am very impressed with the level of detail and research in the book. The majority of the book describes the technical nuts-and-bolts of remote pairing in different scenarios, focusing on remote pairing on open source projects; I think he does an extremely good job.
Author Joe Kutner conducted a lengthy interview with me, and I tried to convey my remote pairing experiences as accurately as possible. I also had the privilege of reviewing an advanced copy of the book. I’m flattered to be featured in the excerpt along with Jay Haynes of Big Nerd Ranch.
I’m most encouraged by the book’s promotion of pair programming in general. Thank you everyone who has ever paired with me, both remotely and in person. I tried to distill the best of our experiences and patterns in my small contribution to Kutner’s book.
Required disclaimer: all opinions expressed in the Kutner’s book are my own and do not represent those of Pivotal Labs, Go Pivotal, EMC, etc. etc.