The Beginner's Guide to Working From Home
Starting a new remote gig, be it a contract project or a full-time job, can be a little intimidating if you're used to going into an office day after day. But this style of employment is growing in popularity, with some very notable companies lending it their endorsements.
As a developer, I've worked remotely for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I've picked up from working in a variety of situations. The advice here ranges from specific recommendations for software and hardware, to tips for hitting your team's deadlines.
I can't stress enough the importance of having the right office setup. It will make you more productive and appear more professional. For example, a headset is crucial for avoiding echo during online calls. Little things like this go a long way when working as a remote.
Here are some tools that I consider essential for my own home office:
- Headset. I really like wired headsets in particular because they don't run out of battery at critical times. You'll be wearing it a lot, so make sure you get something comfortable. I have two iMicro headsets: one for my desk and one that I pack in my laptop bag. As a laptop bag headset, it has two great qualities: because it's USB powered, I don't have to worry about keeping the batteries charged, and it's very cheap to replace if it gets broken in my bag. I find this particular headset a little uncomfortable for long conference calls. If you're doing a lot of those, then I recommend the Corsair Vengeance 2000 -- a comfortable, wireless headset with battery capability, allowing you to work all day.
- A quiet place to think. Ideally, one with a door that shuts -- especially if you live with other people, and especially if you have a family.
- A stable internet connection, or good backup connection. For example, I have DSL and have setup tethering on my phone if the DSL goes out. If you're constantly having Skype issues or dropping calls, you're becoming both less reliable and less professional in the eyes of others.
- Skype. This is good for adhoc conference calls, instant messaging with clients, or even creating low ceremony chat rooms.
- SkypeOut. It lets you take and make calls from your phone to Skype contacts. This is awesome, especially for times when you're away from your computer and (you've miscalculated a time, client has an emergency, etc.).
- Electric kettle. Sometimes I want hot coffee but don't want to disturb my flow to get some.
- Gallon jug of water. For the kettle, or for drinking. For long coding sessions or long conference calls.
Some of these sound obvious, but you'd be surprised at the number of remotes who don't hit all the marks here. We need a quiet space to think, uninterrupted -- a place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term solution.
There are a bunch of good software tools out there to help you overcome the challenges associated with remote work. Here are a few that I really like:
- AwayFind, which is good for urgent emails, particularly last minute messages from an attendee of a meeting, as it forwards their messages to you via SMS.
- Time Zone Converter, for working with clients and colleagues around the world. I like Time And Date's World Time Clock, Every Time Zone, and World Time Buddy.
- Chat/IRC rooms for everyone on the team. This could be formal (e.g., a Campfire room) or just a Skype chat room.
- Bug tracker. For developers, this deserves its own section, so see below.
When planning meetings, always confirm both time zones. And when you get an invitation, you should always do the math backwards and make sure you come up with the same numbers. If the meeting involves multiple time zones, I like including the UTC time also. Since everyone should know their offset from UTC, this is yet another check to make sure everyone's on the same page.
I was on a decently-sized Rails team a few years ago. Several team members worked remotely for at least part of the time, and the team culture was that much work would be done in the evenings. I proposed setting up a chat room through the official team leader at the time, pointing to Campfire or some other paid chat service. Several weeks went by with no action and I decided to setup a Skype chatroom with just the developers, to test my theory that a chat room would be an asset for the team. This experiment proved very successful -- so successful that we just kept using Skype chat instead of another solution. This Skype chat room was still in use when I left the project almost a year later. Sometimes, simple can be the best option.
Later on, during a critical deadline for the same project, we set up a Skype chatroom that included the developers, business analysts, project managers, and the client, so questions could be addressed quickly by the general group. While not as active as the developer-only chat room, it still worked really well. Skype chats can be moderated and controlled by some group chat commands, setting chat roles and setting access permissions, which allows you to really customize the chatroom to your use-case. Even a setup of such simplicity can improve remote productivity.
Best Practices: Tracking
- What am I working on right now?
- What's on my plate for the overall project?
- What are the entire team's deliverables for this project?
Each of these has a purpose. First, "What am I working on right now?": When you work in a traditional office, you have background chatter -- this gives you have a general idea of what everyone else is doing. In my case, an explicit marker in the bug tracker system stating, "Yes, I'm actively working on this right now", can introduce a similar pattern and feel to remote work.
Secondly, "What's on my plate for the overall project?" means, "What bugs I'm responsible for" or "What bugs I'm handling". There's certainly some back-and-forth in every team, but it's also good to know who to ask if you need help about a specific aspect of the project.
It's also possible your team doesn't work like this at all: for example, your workflow might be where each developer is only assigned one bug to start with and picks off the unassigned pile when their one bug is done. This can be productive as well. The "entire team's deliverables" doesn't have to be anything big. But it's still good for everyone to know what's coming up. Especially if you pick off unassigned tickets when your current ticket is complete.
Note: I've included some recommendations for specific bug trackers at the bottom of the post.
Best Practices: Team Communication
For some, team communication is the most intimidating part of working as a remote. But this will only be an issue if you let it be. In an office, as you stroll by everyone on the way to your seat, there's a bit of banter, people saying "hello". Your coworkers know you're at work because they see you, over there, at your desk, working.
Remote workers need to be slightly more explicit -- nobody knows that you're working unless you tell them. But if you establish the right communication practices, your colleagues will be available at the press of a button, rather than a stroll across the office, down the elevator, etc. These tips apply more for a remote worker as part of a bigger team, but may be useful if it's just you as the sole developer.
Making Your Presence Felt: Don't Go Invisible
I picked up several of these ideas from the Wide Teams Podcast Episode 48. At beginning of the day, get on IRC (or whatever tool your team uses) and say "hello", chat about how people's days are going, etc. Even if it means getting on IRC and asking about kids, weekends, sports teams, or weekend hacking. When people know you're currently hard at work, you don't become invisible. Build a relationship and let people know that you are there.
Chat with people on chat and make sure you stay involved with your colleagues. This is different than when you bump into people in the coffee room, etc.. You need to explicitly reach out and stay in touch so that when you need assistance, people are ready.
'Starting Day', 'Lunchtime', and 'Be Back' Messages
Along with making your presence felt, you should also let your teammates know when you're not working. Just like in a traditional office setting, you don't want to disappear for the rest of the day and leave your colleagues hanging. If you're on a team with a number of other people, it makes sense to check in when you start your work day. Use a simple "Good morning, everyone" to let people know that you're at your desk ready to start work on the project, and no longer at home or in bed.
Sending "Be back in 1 hour" messages for lunch or work breaks during the day is nice too. Remote work is great for many things, but one worrisome scenario is that you ask your colleague a question and receive no response. Are they not responding because they're away for 30 minutes? Or because they are deep in the zone and not listening to chat? Maybe in a meeting? "Be back in..." messages can alleviate these concerns and smooth out the workflow. When you're done for the afternoon, let people know when you'll be back. Maybe it's "See you all in the morning", or "Be back later this evening to get [x] done". But like the "Back in 1 hour" messages, they set a certain expectation to which your team can adapt.
There's an interesting startup called Sqwiggle that may solve some of these problems (although I haven't tried it myself yet). In addition to taking a picture of you every few seconds, it also lets team members click on your picture to start video/audio chatting, as well as providing a text chat component. The idea behind the picture is to see, at a glance, if you're at your computer or not. (There's nothing worse than trying to chat with someone online and not hearing back quickly. Are they caught up with something else? Deep in the zone? Don't see the chat notification? In the bathroom right now?). I heard about Sqwiggle on the Wide Teams Podcast Episode 83.
On Projects Where You Can Setup the Best Practices
Remote freelancing gigs are always different. (That's part of the appeal!) Sometimes you're brought into an existing team purely as staff augmentation. Maybe this team has been together for some time and, in that case, they've already established communication practices. On the other hand, sometimes you're the only person on the project, working with a non-technical client. You can setup your own software development best practices and have some control over how to run the operation. Below are some best practices from my decade or so of remote work experience. Mostly, these are targeted at half-week (20 hours/week) or full-week schedules (40 hours/week).
There's something to be said about holding standup meetings to talk about the state of the project. These are very common in traditional offices, but there's no reason why they can't be productive for the remote team: they're just another way to enforce communication between the two parties: client and developer. A traditional stand-up meeting asks what you were working on yesterday, what you'll be working on today, and if there are any obstacles in your way. This format may or may not work given the size of your team: if it's a single-developer project, then these actual questions make no sense.
How often you should have a standup meeting is really dependent on team size and culture. However, here are my recommendations:
- 1-3 people: 2 standup style meetings a week
- 4+ people: daily standup meetings
With 1-3 people, these questions are mostly self-evident: you know what each person is doing because it's easy to track their individual work. Everyone knows what everyone is doing, because there's just not that many people doing work. With larger teams, there are more parts in motion: you want to make sure that nobody is stepping on anyone's virtual toes by replicating work or making incompatible changes.
If you do happen to walk into a team where you'll be establishing the best practices, I've listed some tools below for managing your remote work. Keep in mind that these are just my recommendations (and are tailored for developers). Certainly, these aren't for everyone, and if you don't like these tools, there is probably something that fits your needs better.
- Planscope.io, in weekly mode. This is a time tracker + bug tracker + project estimation tool that sends clients daily emails when you work on their project and lets them see how things are going in terms of progress and budget. This is great for projects of 1-4 developer/months in size.
- App Trajectory is a bug tracker for small developer teams with a focus on estimating and breaking the project down into one-to two-week chunks. App Trajectory can tell you how much work you're completing in an iteration, and how many iterations until all the known work is complete. This is great for projects 2-12 developer/months in size.
- Pivotal Tracker is a bug tracker tool for clients with a focus on Agile methodologies. This is great if you are doing formal Agile iterations or have a project size measured in developer/years.
- FlowDock for chat. Flowdock offers some advantages over plain IRC or Skype chat. In addition to integrating with popular services, it also lets you tag conversations for quick reference later. FlowDock also keeps a list of status activities (code checkins, etc.) which are separated from general chats. (i.e., in the web interface, automated status updates are on the left, while chats are on the right.)
- Again, Campfire is also great for chat.
Getting started with remote work can be quite an adjustment, both for you and the client. I've had it go very right, and very wrong. But when it goes right, it can be an excellent way for clients or employers to solve the "talent crunch" problem, and create a wider range of opportunities for people who live outside major cities or business hubs. There's a whole world of efficiency to be gained from people working together remotely with the right best practices in place.