When I first chose my own adventure, I didn't know what working remotely from home was going to be like. I had never done it before. As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards. All the same, I was worried that I'd go stir-crazy with no division between my work life and my home life.
Future of work. Yeah, right. Right as our very industry has gotten on the scrumtrain - you know, the one that says that people must work face-to-face, in open office environments, and have a meeting every single morning at the right time, and should use sticky notes instead of electronic tools.
Hey Jeff, I’ve been working remote for about two and a half years now, and I generally agree. A couple of ideas:
Pair Programming. Yes, you can do it remote; use GNU Screen, and you’ll find the latency of just pushing ASCII text is actually pretty good. (You are using Linux/Unix/Mac right?)
Set up an Asterisk server so VOIP is free, then do pair programming with VOIP ALL THE TIME,
Use VNC for screen sharing when you need to debug an issue
If you’re doing fancy javascript and have cross-browser compatibility issues, you’ll likely want to start getting to testers to help out, and those guys don’t have to have code coming out of their ears. Likewise product management folks and graphic design. But for coders, sure, hard-core is good.
I wish you the best man; sounds like you’re doing it, and doing it well.
Jeff - How material are the benefits? Do you think productivity goes up?
I suggest recording some meetings and make them available to the new people when they join the group. It really helps them gain some context and learn the thought processes that went into how you got to where you are now.
I think you hit the nail on the head. Remote work is about the chemistry of the team. If you don’t have at least 1 person that is your coding buddy, then you’re generally not going to be great at working remotely (this concept doesn’t seem to be unique to remote…). Any difficulties I’ve previously had with remote work boils down to some lack of teamwork among coworkers that makes it completely unproductive.
Personally, I long to be a part of an exceptional distributed team.
I work as a 1-man team. So all of those issues you mentioned with working alone, remotely, I experience on a day-to-day basis. It’s tough, really tough. My last job consisted of 8 developers, so I was able to quickly discuss problems, solutions, or ideas in general with 2 or 3 others pretty quickly. You don’t fully appreciate the value of that until you’re not able to do it any longer.
I hear your point. I’m programming in academia, totally and completely alone. It takes a lot of discipline to make things happen. Programming is a collaborative effort. If you take that away, it’s rather dull, because you don’t learn anything. it’s just you, your problems, and your documentation. On this regard, StackOverflow had another great advantage: it made me feel less alone in my work. As a developer with a problem, not having any colleague to talk with, but having the SO community at a quick click of a button was precious.
Hey Jeff,
When it comes to team and individual status reports, I highly recommend using blogs or a wiki. There are a ton of tools you can leverage to do this. The nice thing is that they become backed up, searchable and even subscribable via RSS.
This is also something Google Wave looks very promising for, though I haven’t personally tried with that. I’ve definitely had good results with blogs and wikis though.
Also, it goes without saying in most cases, but remote development DEMANDS that you follow all your tried-and-true, software engineering practices like using source control, automated testing, continuous integration, etc.
I generally like to keep tabs on teams like Apache, Spring and OpenBSD for guidance in these practice areas. They are truly effective at doing this stuff.
Good luck!
Sam Wilson
I work in Michigan for a company in San Francisco on a team of 4 developers. I am the only remote dev, and it can definitely have its pluses and minuses. You did a decent job highlighting what comes along with having remote teams.
I have worked remotely in a couple of different settings and personally love it. It definitely works for me, even without a coding buddy, and saves me tons of time in commute and stress from not having to look at cubicle walls or sit up straight all day.
“Only grizzled veterans who absolutely love to code need apply for remote development positions. Mentoring of newbies or casual programmers simply doesn’t work at all remotely.”
This sounds like the typical yet completely wrong advice that “agile is only for companies that are ok with risk”. The reality is that agile is for ALL companies and helps manage risk better, but since it exposes the inherent risks in development, then people conclude it causes it.
The reality in this case is that “only grizzled veterans who absolutely love to code” make a ridiculously large and valuable contribution to any software development team, way out of proportion with a newbie or competent programmer. That is not as obvious when we all sit together in a room and code for 40-50 hours but becomes much MORE obvious in a distributed environment. A newbie who would not be able to successfully contribute much in a distributed environment would not be able to do much in a co-working environment either, but since they show up for the same amount of time, somehow our brains just don’t notice or care.
I’m not making the case NOT to hire a newbie or barely competent programmer, as there are many benefits to having them (at least the newbie ones). You get a fresh perspective, you can build loyalty and grow a great programmer (if you play it right), etc. But for too long managers and companies have ignored the massive productivity differences in programmers of different skills. I am making the case to make those as transparent as possible, and working remotely (among many other benefits) is one way to do that.
Some good tips in here, we run a fully distributed team and had overcome similar challenges.
One tip I would add is pair-programming on complex parts or sticking points through screen and vim, we have an ec2 instance dedicated for pairing which everyone has access to.
Hey Jeff,
Another thought… when it comes to pair programming, sometimes it’s possible to utilize screen-sharing or other tools, but if you’ve got timezone issues, that can be problematic.
One thing I’ve done in the past that was pretty effective, was to basically require all code check-ins to be peer reviewed. This did a number of things. First, and most obviously, it meant that code reviews were being done on a regular and ongoing basis. Second, it meant that at least one other person was cross trained on your code. Third, it forced us to keep our code check-ins relatively small and discreet. Big, ungainly check-ins made the peer review process difficult. So, best to keep things small and manageable.
Most importantly, it fits nicely into the distributed, disconnected nature of working in a remote environment.
Sam
I found out some of these things the hard way. My first programming job that moved from in office to remote led to a zombie-like state where I couldn’t keep track of days, or even weeks. Now I make sure any remote work is done with another programmer elsewhere and with improved organizational skills it is quite enjoyable and easily managed.
The company I work for doesn’t have an office as such, we all work from home. I’ve worked from home since early 2003 and would find it very strange to go back to working in an office full time again.
What is also important is that your remote team members are provided with separate business telephones, broadband and computer(s). This provides a ring fenced work environment within the home office and the mental flag that “this is work stuff”. You also don’t get hard feelings where folk feel they are providing a freebie to the business of their own phone, connectivity and hardware.
One of the things I do miss is white boarding sessions in person with other devs and general office banter. But that said, we’re still a fairly sociable lot over MSN and the phone anyway.
“If this seems like a lot of jibba-jabba” - actually, it sounds like a lot less jibba-jabba than I just sat through in my software engineering class in my Master’s program in Computer Science at a top-tier university.
The main things I learned from that class are that colleges can’t teach software engineering, the type and size of process needed varies wildly among projects, and I now have a list of buzzwords to listen for during interviews, upon the hearing of which I shall run screaming from the room.
This article was fantastic and well-timed. I’m programming alone on a research project, and I’ve felt many of the issues you’ve pointed out (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).
Some of this isn’t exactly what I wanted to hear: I like the idea of working remotely, but I don’t think I’m ready for it. I need more experience working on good and bad teams (hopefully more good than bad) first.
How do I know if I’m good enough to work remotely? Compared to my college peers I’m a better-than-average programmer but, being a college student, I haven’t had many opportunities to compare my skills and productivity with professionals. How can I tell if I’m cut out for remote work without spending a decade in the workplace becoming a “grizzled veteran” first?
At the risk of plugging my own thing on somebody’s blog, this situation is the reason we built Twiddla, so I’d recommend you check it out.
Mostly it was to deal with communicating little graphical changes to the site to remote designers without resorting to MS Paint and email, but it does chat and voice too, so it pretty much wraps up your whole “tools you need” section in one thing.
What little professional experience(couple of years) I have, I’ve been largely working remotely. I wouldn’t recommend it to anyone just starting out as a software developer. There just are too many things that are too easy to miss out on. Like, you know, the whole social aspect of working. Early on in your career the job itself is enough of a learning experience not to burden yourself with working remotely. YMMV.
Another thing: working remotely as a part of team is definately easier and more pleasurable than working remotely as a lone wolf. Especially if you are the lone developer of the company, then it is pretty tough even if the work itself is pretty simple.
We’ve managed to work remotely with newbie developers just fine. We haven’t needed voice or video chat, either. But then again, we’re also very experience with working on tasks remotely in a way that most programmers aren’t.