Two computers and a microphone

about me presentations

How to Work Remotely as a Software Developer

23 May 2013

Working from home gives you the freedom to get a lot done, away from the distractions of office life. On the other hand, it also gives the freedom to goof off all day!

I've worked remotely with 8+ colleagues for over a year at Wave and with Nathan Bertram on ArrangeMySeat for even longer. Here's some of the knowledge I've gleaned from that experience.


Working remotely gives you the freedom of picking your own office. How great is that? Key to that is picking a space that's appropriate. Here's a few things that I find that help:

Having a space to work that you can ignore people is key to getting work done. Constantly being interrupted by people you live with or other people will kill your productivity.

Adding onto the ignoring people guideline, working from a coffee shop is great. People will ignore you, you get hopped up on caffeine, and there's a constant noise level about you.

If you're working from home, find a room or desk that you can use just for work related stuff and keep it that way. If you're working from on your bed, you'll soon associate work with sleep and/or vice-versa. Remember, bedrooms are for sleeping and sex, not work.


Having a routine is something that a office worker takes for granted. They're forced to leave their house, travel (which takes time), and then begin work once they arrive.

With someone who works remotely, there's no segregation between the time they're at home to when they're at work. That time that's spent traveling to work is reduced from 15-60 minutes to 0 minutes.

Another problem is that you're surrounded by things that aren't necessary for your job. You don't watch TV at work in the office, but now that you're at home, you have the option. Resist the temptation! Distractions, not even once.

Developing a routine helps immensely. Once you begin work (in your workspace!) at a preordained time, you tend to not be tempted or distracted. Taking a lunch break at the same time each day helps. Make sure to end work at a preordained time as well. You're much more likely to get your work done in a predictable and sane manner once you develop a routine.

Setting Limits

One of the problems of working from home is that the separation between work and home doesn't exist so you may find yourself spending more or less time than you should on work. Because of this, setting limits is paramount.

The idea behind setting limits is that you're in a profession. Spending time outside of your obligation on work should be done with caution as you have duty to respect your own time and sanity.

On the flip side for your employer, they should also be concerned if you're working more than agreed on. From the employer's perspective, you're risking burning yourself out if you work 50-60 hours a week. Also, when you invariably need to pull some overtime to get something done ASAP, where's that time going to come from? Suddenly, working 50-60 hours that week isn't enough and you're spending most of your waking hours at work to get that critical project done. Respect yourself, your employer, and your profession by setting limits.

To know what the limits should be, you need to follow a few guidelines:

  1. Work the amount of hours you agreed to with your employer
  2. Work at the same time as your team
  3. Work during a period that overlaps with your team if #2 fails

That's it! I wouldn't recommend working off-hours as the turn-around time to get issues resolved from your co-workers suddenly turns from a few minutes to 8+ hours (whenever your team is online next). If you're developing solo, do the development work when your stakeholders in the project are available.


Timeboxing is allotting a fixed amount of time for a certain task. I love this technique because it protects against two things:

  1. Perfectionism
  2. Procrastination

There is perfectionism that is rampant within programming that probably affects yourself. Having a maximum limit of time to do something (or to try to do something) will limit you in your quest to produce The Perfect Code™. Remember, any problem can become a time suck.

As to the procrastination, it is also a hot topic within the programming community. Having a set task to do actually accomplish something gives yourself the accountability to commit (pun intended) and do it.

Now, specifically, there are many timeboxing techniques out there. One of the most popular and famous techniques out there is the Pomodoro Technique which advocates 25 minutes blocks interspaced with varying amounts of breaks. If you're having trouble switching between tasks and need a lot of structure, then this technique may be for you.

Personally, I prefer allotting a task or a set of tasks in 1 hour slots because that it's not too short of an amount of time that I'll constantly exceed the amount of time I've allotted for the task I'm working on and not too long of a time such that I get stuck wasting my time trying to figure out a problem. If I'm not done after an hour then I can ask myself questions like:

With the timeboxing technique, you're forced to consider these questions instead of blindly ignoring them for the day. Having someone in-person to ask a question (or be interrupted by) is a luxury of the office and pausing to ask questions and interact with people is extremely useful while working from home.

Everyone has a timeboxing technique that works for them – go out there and find it!


This may come as a surprise to you, but communication is one of the most important skills to have as a programmer. The better you are at communicating, the better a programmer you are. In fact, you could even say that it's not things, techniques, or even programming languages that get you rich, it's people (no one got rich on their own!).

Getting back to the discussion at hand, communicating is what enables you to not only get the job done, but more importantly to get the right job done. So much time is spent on work that's scrapped because the wrong thing was created. Agile methods aim to minimize this, of course (and I hope you're practicing them), but if you can't get your point across (or vice versa) then the wrong thing is still going to be built.

As a remote worker, you may feel that you're interrupting someones work by pinging them with a question. Don't fear this! Everyone has their chat programs or email set up so that it bothers them in an appropriate way for them. While you're working on a team (or with a stakeholder), the collective work that is done will be better if you communicate to them earlier.

Quick feedback on ideas is paramount to getting stuff done and email is not a good medium for it. Not being able to bounce ideas quickly off a colleague or a stakeholder can be a stranglehold on your time and schedule. Without that quick feedback, you may end up either waiting for feedback (minutes/hours lost) or building the wrong thing (hours/days lost). To get that feedback, I recommend communicating with them by any other medium except email (see a list below for specific ones).

Back and forth emails really suck: there's an extreme time-delay between each email and both of you (or N number of people in the conversation) are constantly context switching every time you have to read or write an email. Getting on Skype with the person or people can yield much better results.

Working in a group can create a productive atmosphere. As a remote worker, you lose some of that so you have to really make the effort to communicate through all the channels that are available to you (mailing lists, issue trackers, chat, IM, IRC, email, etc.) to gain that atmosphere back.

You should be using most, if not all, of the following techniques in order to communicate to remote parties:

Think about a normal day at the office for a second and contemplate how much time you spend talking with your colleagues. Are you spending the same amount of time remotely? Why not? Keeping the channels open to your colleagues is incredibly important and an effort really has to be made.

Closing Remarks

Well, that's a summary of the knowledge that I've gleaned from working remotely. Hit me up on Twitter if you want to chat more about it. I'll submit this to HN and reddit soon and we can have discussions in those forums.

edit: the hackernews discussion
edit2: the reddit webdev discussion and the programming discussion

comments powered by Disqus