Saturday, January 15, 2011

Reflecting on Being Employed as a Remote Pair Programmer

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected.

The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technical problems, and building solutions.

It is not the "remote developer concept" that many have in mind. I worked from my home, but did not make my own hours. I did not go to an office by day, but also did not work for myself. I could not take arbitrary days off as self-employed or many work-from-home people often do. It worked well for me and for my employer.

We found a pretty sweet combination by using Skype for voice and video, git for version control, and Webex to do screen sharing. The latency for webex is surprisingly low, and suited our needs very nicely. I set up a netbook with a built-in camera for skype so the company laptop's CPUs could be fully devoted to programing and screen-sharing (so necessary when using cpu-hungry development tools). An Asus EEEPC netbook is under US$300 most places, and mine really does a great job. I have had a few headsets. They're inexpensive, but they also tend to get uncomfortable after a few hours, so I would definitely try several. I used a few logitech models and was more-or-less satisfied.

The other useful tools for a remote pair partner? I second monitor (a large one) and synergy. Synergy allows one keyboard and mouse to be used by multiple computers. It is easy to setup and use, and allowed me to switch between netbook and work notebook very easily. I found myself mousing among three screens attached to two computers, and never thinking twice about it. It all just became transparent.

If your organization is interested in using remote teammates, I cannot over-recommend the combination of WebEx, Skype, Netbook, Work Computer, Synergy. For very little cost, you have a powerful pairing system.

There are shortcomings to being a remote pair-programmer, though. You are not visible to your bosses, and can be forgotten sometimes. You do not participate in the conversations at the next cubicle, in the hallway, or at lunch. You don't see the same visual cues as to the team's progress. You can't feel the emotional charge in the room to know when people are afraid, tired, angry, or excited.

A remote does not have the physical presence necessary to be an agile coach or effective scrum master. Email and text will not truly fill the gap of rich, human communication. Your view of the team is the webcam. That leaves you out of mentoring opportunities, so you learn and teach less than you could have on-site.

Remote meeting participation is awful. The room is full of people, and there are one (or a few) mics. Inevitably the people doing the most speaking will be furthest from the microphones, and the most fidgety people will be close to them. There will be long stretches when you can't make out what is being said behind the rustling papers, pen clicks, rhythmic tapping, layers of whispering, etc. The worst interruptions in sound are caused by the the other remote who is on speaker phone but didn't mute their mic. Every time a sound activates their mic, all other sound on the line is cut off. It is almost as if someone were toggling the mic in the meeting room. One can lose interest in trying to keep up and return to coding, missing the reason they were invited to the meeting in the first place.

Finally, a remote is harder to promote and easier to release than a body you see every day in the office. That might be seen as an advantage to an employer, but will probably seem a little off-putting to the remote employee. My intention was to try remote development for a quarter or two, yet we stuck it out together for over two years. That's a pretty nice experiment, and I thank GeoLearning for the great and mutually-beneficial opportunity.

Would I be remote again? I think I would. I would remote with the same team in a heartbeat, because they're good people and we learned how to do this together. I still learned, connected, and enjoyed software development with good people. But I think I would like to go onsite again for a while. However convenient it is to be distant, programming is still a social act and still best done shoulder-to-shoulder.