Starting a new remote or work from home 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.
I’ve successfully worked remotely using these tools 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 for working in a variety of situations. The remote and work from home guide 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 both 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 toolsfor working remotely that I consider essential within my own home office:
Some of these sound obvious, but you’d be surprised at the number of remotes who don’t hit all the marks here. As developers, we need a quiet space to think, uninterrupted. And as remote workers, we need a quiet place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term remote work solution.
There are a bunch of good software tools out there to supplement your typical development environment and help you overcome the challenges associated with remote work. Here are a few that I really like:
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 offical 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 analysists, the 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.
I like to know three things from a bug tracker I’m using:
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. 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 next release?” 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 want to grab a bug, or need some help with finalizing your bugs for the release.
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 “Next release of the software” doesn’t have to be anything big–I’ve been on teams where the “next release” meant, “3 days from now, we’re going to release a new alpha build for the client”. But it’s still good for everyone to know what’s coming up in this new release. Especially if you pick off unassigned tickets when your current ticket is complete.
I’ve included some recommendations for specific bug trackers at the bottom of the post.
For some, team communication is the most intimidating part of working remotely or from home. 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 remotely managed employee as part of a bigger team, but may be useful if it’s just you as the sole developer.
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., 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 at home, 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 then when you bump into people in the coffee room, etc., etc. You need to explicitly reach out and stay in touch so that when you commit code or need assistance, people are ready.
Along with making your presence felt, you should also let your remote 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 developers or managing remote employees, it makes sense to check in when you start your work day. 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 worrysome 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.
Remote freelancing gigs are always different. (That’s part of the appeal!) Sometimes you’re brought into an existing team of developers 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 developer 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:
With 1-3 developers, these questions are mostly self-evident: you know what each developer is doing because it’s easy to track their individual work as they plow through tickets: everyone knows what everyone is doing, because there’s just not that many people doing work.
With larger remote 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.
Advanced remote teams may have other methods of keeping all the stakeholders on the same page without scheduling an actual meeting while they work from home. I still like getting on the phone/Skype/Hangouts with someone and having a meeting that way.
For small teams, two standup meetings a week works really well: course corrections are made quickly, but developers still have something substantial to report during each meeting.
Depending on the size of the project, I like deliverables sent to the client weekly for small (1-2 developer), and bi-weekly for larger (3+ developer) projects. This rhythm gives developers enough time to complete sizable chunks of work, including an interface (or improved user experience) for the client to see.
It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.
Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.
Depending on the type of software project, not all of these client releases will be released to the public. For example, if you’re working on a Rails project, you may want to deploy approved changes immediately; on the other hand, with a mobile app, you may call a release “1.3a10”, but the current release is just part of the bigger feature set of a new 1.3 version of the software that will be deployed later.
This is where the remote bug tracker best practices come into play. With bug tracking, the client knows:
The client knows what to expect from this release, and developers know what work is ahead of them.
If your remote team is mature enough to use continuous deployment and/or Kanban then that’s fine. However, these are both very advanced techniques that are more suited towards organizations with a strong, developer-based culture. Most organizations, where custom software development is seen as necessary but costly, are probably not ready for either of these techniques. Why’s that? Two things I’ve seen is that the client can’t keep up with the number of changes developers want them to review, or priorities change too rapidly for development to get any one thing done.
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: certainly, this guide isn’t for everyone; and if you don’t like these tools, there is probably a tool that fits your needs better.
Getting started with remote or work from home 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 developers who live outside major technological centers or “startup” hubs. There’s a whole world of efficiency to be gained from developers working together remotely with the right best practices in-place.
This article is originally posted in Toptal.