On Working Remotely

In this quite lengthy blog-post there is a great section on remote pair-programming that may relate to distributed teamwork presented above:

http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/

“Tim M wrote: (on top of which I’m a novice programmer, as these things go: only three years of actual experience and that with a giant pile of legacy code).”

3 years shoud make you more than novice. And working with legacy code is an essential skill to any programmer - debugging other people’s code - good and bad - teaches you many lessons.

Generally: There are some great commercial and open source tools now to support remote and distributed working. I have used webex and similar for oline collaborative working; IM; Skype; Google docs for document sharing and various others. Thoughtworks have some great tools and they are now looking to integrate those with Google Wave, which should be interesting.

Distributed VCS is now available, automated test management tools from unit to system (Junit, Selenim et al), online PM tools for agile project management and the plethora of wikis, blogs, facebook type apps and so on.

For those working out of Eclipse, the Eclipse Communication Framework would be a boon.

Combined with an XMPP(S) server, such as openfire, you can have a controlled IM system, chatrooms and shared editor, allowing both of you to edit an individuals local copy of the code in realtime while keeping your copy clean.

Along with this is of course basic file & screen shot sending utilities.

You can of course keep chat logs, but there are better tools for meetings and doc sharing, especially for collaboration.

A googlewave plug in for eclipse would be a killer feature.

Amen Jeff.
I’ve been doing this for a decade now - working in a small team in a big company from across the world. My current team has had up to 5 timezones in 3 countries at time. I’ve often considered blogging about it, but my first post would have read just like yours:

IM is crucial (didn’t have it when I started) as a replacement for over-the-cubicle-wall chatter.

I would add that with the right attitude you can be hugely more productive when not constantly interrupted by general meetings, birthdays, wanderer’s by and so on. I miss all that to some extent true - but on those rare occasions when I fly in and visit the mother ship, and spend some time in a cube, I start to wonder how anyone gets anything done (or how I did back then)

I agree there are times when being there is very beneficial, however overall this loss is outweighed by the productivity gained by working alone.

On a technology note: If the advent of IM was a real boon to this way of working, the advent of VPNs around 1999 was an absolutely essential part of making this possible - if you’re doing it for a big company.

Blanket statements tend to over generalize to a startling degree.

Newbie programmers, or competent programmers who are phoning it in, are absolutely not going to have the moxie necessary to get things done remotely – at least, not without a pointy haired manager, or grumpy old team lead, breathing down their neck. Don’t even think about working remotely with anyone who doesn’t freakin’ bleed ones and zeros, and has a proven track record of getting things done.

The only important part of this sentence is “gettings things done”. I’ve been working in the office four days a week and one day a week remotely largely doing development work for the last four years and it doesn’t really matter where I am working. If you have the experience, creativity and drive you will get things done.

Malcolm

You say that mentoring remotely shouldn’t even be considered… but don’t projects like [Google/Ruby] Summer of Code rely heavily on remote interaction between the student and mentor?

I understand that mentoring in a production environment would be far more stressful than mentoring a low risk project, i.e GSoC; but to flat out say “mentoring of newbies or casual programmers simply doesn’t work at all remotely” is wrong.

I for one would kill to just watch a remote-desktop stream of someone working on StackOverflow’s unicorn-backend and give my feedback over a VoIP program like Ventrilo.

If working remotely is truly the future of work, then it should be the future of mentoring as well. Unless it’s high-time we got rid of on the job training?

I disagree with your positon re: newbies. What you really need to succeed in a remote or any isolated work environment is a strong work ethic.

The recipe for success is to find smart people that are motivated to work hard, maintain social connections and get things done, and add some good leadership. If you can attract and retain top performers in their craft, that’s great, but isn’t really relevant to remote work.

I’ve worked with a few folks that I would consider absolutely brilliant in various roles who would wither in a remote work environment – especially in an org with more than a dozen people. They need that social contact. Conversely, I’ve worked with folks who as a programmer or engineer weren’t at the top of the heap, but had the people/social skills to thrive in any environment – they would still be contributing if their connection to the rest of the team was morse code over shortwave radio.

Most people lie in the middle, obviously.

For quick remote pair-programming sessions, I second the nomination of GNU screen + Google voice chat.

If you haven’t used screen, here are basic instructions to get multi-user working:
http://dustwell.com/screen_command_to_pair_program.html

I’m curious about Leetdoodsnonexistentramblings.blogspot.com’s assertion that using a MOO would help with collaboration – and even asked a question on SuperUser about it. Does anyone have any thoughts on how this would facilitate collaboration?

I have been working with teams that are spread across countries (USA, India (Bangalore and Chennai) and europe). It has its own advantages but there are pain points to if teams are not ready to cooperate.

I agree. Future is in global teams.

The other problem is that once you’re senior enough to merit working from home, you are quite likely to be expected to mentor more junior people - who don’t, can’t, or aren’t trusted to work from home. Oops.

Again, this kind of thing is a fantasy - vastly oversold - in my other hobbyist field (transportation); most people will never and can never telecommute for more than a trivial number of days per year, period.

FINALLY! Someone willing to say remote development is hard and that it takes time to get it right. Great job! We just merged with our development partner in Costa Rica and we do nothing but remote development. I think we’re pretty good at it but that’s because we spent the time to do that, to understand what type of engineer it takes and how you manage the project. Here’s what I would add:

  • You should always hire awesome developers remote or not. The bar should be high even if you sit together.

  • The best engineers we have found for remote dev are the ones who know how to ask questions back. The product owner is counting on you 100% to see when the product is not coming together and to escalate that up. Like when you spoke with Joel, he is counting on you to know what needs to be discussed most of the time.

  • Remote with only 1 guy? Really tough to do well. Plus, most guys who are good enough to create killer products alone don’t touch the ground between jobs.

Bob Benedict
Avantica Technologies

Jeff,

Really great points on a super important topic. All your ideas are spot-on. I’ll add five more observations that I think are strategic problems for everyone dealing with distributed software teams:

  1. Fundamentally a lot of the hard problems in software still come down to getting a group of intelligent folks to huddle around a white board and brainstorm. Powerpoint and Skype just does not provide an effective medium for that dynamic.
  2. When I interviewed James Gosling, inventor of Java, in Making it Big in Software (http://amzn.to/b08auR) he raised a key issue around mentoring. It’s really hard for the next generation of up and coming software engineers to learn and grow from the gurus in their organization when they are remote. This poses a strategic problem for any organization, because your future depends on building that next wave of talent.
  3. Team building is important too. There’s a limit to how much trust and esprit de corps team members can build across Skype, instant messaging, and telecons.
  4. The time gap can be disruptive, especially when it’s more than two or three hours. Try doing a daily scrum when you have some people in Palo Alto and other in Beijing!
  5. From the individual programmer’s perspective, remember that if you’re out of sight (off site) you’re probably out of mind. It requires a much larger effort than normal to stay connected, and stay front of mind with the people who decide your next promotion or salary increase. To protect your career when working remotely you need to spend a lot more time communicating to others what you are accomplishing, and trying to maintain some social connection with people at the core of your professional network. I think a reasonable way to think of this is that for the 2 hours you’ve saved commuting, you’ll need to invest an extra hour every day in communication. It can still be a net win.

From the team’s perspective, if the finances allow it, there is still a lot of value in bringin people together face to face, even if it’s just once ayear, and even if it can’t be the entire team.

Technology is improving the effectiveness of distributed teams, but we are far from having an elegant solution. We’ll find the elegant solution eventually. I hope it’s soon.

Sam Lightstone
Author, "Making it Big in Software: Get the job. Work the org. Become great."
http://MakingItBigCareers.com

What’s all this about humble characters being insufficient to fully and effectively communicate online??

Why, I oughta… ಠ_ಠ

M1EK: I don’t think what Jeff is describing excludes agile at all. There is no reason that face to face can’t mean video chat. I approach any of these development philosophies as guidelines not a rigid set of rules. Adapt and use them in ways that help you and your company.

Work Ethic, as mentioned by others, is the ONLY requirement for remotely working, regardless of field.

The people with the highest work ethic, in general anyway, are the same people who absolutely love their jobs. Most coders that I know love to code, regardless of their talent level so most coders are fine working remotely.

I’ve worked with all levels of programmers, from true coding genius’ (which are very rare IMO) to expert programmers to moderate and casual and novice programmers and the only thing that makes any of them work well remotely is a strong work ethic. Programming isn’t about talent, its about understanding of logic and structure. What a novice doesn’t know he can easily learn provided his understanding of HOW things work is there.

JMO. Newbies are just fine to work with and in fact, can be a benefit as every app, web or software based, has parts that are easy yet tedious that more experienced programmer’s can’t be bothered with yet newbies can do while letting the experienced programmer’s work out some of the more difficult tasks.

I’ve been working from home ( one man dev team ) for the past year. I like it, and have no problems motivating myself.

Like working in an office, it’s not for everyone. I’ve found it’s a little hard to find employees / contractors that are willing / able to take instruction / give updates over the internet, but they do exist.

Some tips and a pros/cons list of my experience coding remotely. https://coderwall.com/p/0ikc0w?i=1&p=1&q=author%3Alee101&t[]=lee101

It’s a great article. Now I’m trying to understand how remote working works. Jeff talked about a kind of programmer named TOP PROGRAMMER and I was asking to myself what kind of knowlegde or experiences I must have to be “a top programmer”. Can I revive this old topic? Thanks in advance

This aged quite well, interesting.

We needed Covid for everybody [that is, especially companies] to realize that home office can totally work, though.

2 Likes