What I've Learnt From 3 Years Remote Software Development
Intro and my story
I've been working remotely, at the awesome ByBox, for three years now. Well, I tell a lie actually, it's three years sometime in late June 2016.
I'd like to say that I've learnt so much about remote working that I'm now a master but I don't think that's true. It's a constant learning and improvement experience.
When I first started remote working I had a bit of a wobble, so much so that I handed in my notice after just a few months. I'd expected everything to be great and this new found flexibility afforded to remote workers would increase my happiness at work but the reality was somewhat different.
I struggled to settle in and started to feel a bit like a fraud, how could I possibly get such autonomy? I felt it a privilege to be able to work remotely, one I wasn't sure I had the right to or was "smart" enough for.
I've always had a tendency towards feeling incapable or inferior to other developers, even when other people's opinions tend to indicate the exact opposite. I'd say it was imposter syndrome but then I'd have to think of myself as a high achiever, which is far from true. Remote working amplified this inferiority complex.
You could argue, and you would be right to some degree, that I experienced similar things while working in an office every day. The difference was, it took me much longer to settle and find my place within the team than it ever did previously when I was working in an office.
On-boarding process
I think the new developer "on-boarding" process is key to taking on remote developers. This process has usually taken one of two forms in places I've worked:
- New developer works on an isolated but worthwhile project, maybe to improve system monitoring or similar.
- New developer goes straight into a "real world" project, working on something key to the business.
I think each of these has positives. Working in isolation on a worthwhile project could be considered more straightforward for a new remote developer. There are less things to deal with, probably less initial "learning about the business" and it perhaps offers a more relaxed entry point, especially for someone who hasn't worked remotely before, at a time when that person may already be bombarded with new information.
In some businesses it may also allow other people in the team to monitor the work of a new developer and understand things they are particularly strong or weak at, without hindering a "real project".
I've often looked back to the time when I started remote working. I worked on an isolated "system improvement" type project and thought of it as a blessing. Things like "How would I have ever coped if I was dropped straight into the deep end" come to mind. More recently I've started to think that maybe it wasn't that helpful though and even worse it could have actually been a hindrance?
It's all great working in isolation to get started but I found it quite difficult emotionally, maybe it's just me, as I said I'm prone to that kind of thing! It wasn't until I started working on a "real project" that I actually started to feel like I was doing something worthwhile, like I was part of a team that strived to achieve good development practices and deliver value to the business. Exposure to the rest of the team and the more "real world" nature of the work also helped to bring my expectations in line with reality.
Throughout the hiring process and during the "on-boarding" phase I built up an unhealthy, unrealistic expectation of just how amazing I would need to be in order to make remote working a success. I valued the skills of fellow developers much higher than my own, this was a mistake though, it's a cliché but everyone brings unique skills and different experience. Only working with my new team "in the wild" really enabled me to see the real world view of this and to understand that there are technical things even they don't know, that they too have insecurities, and face similar daily problems.
Given my experience I'd argue that the best approach is to integrate a new remote developer with the rest of the team as quickly as possible. I know we often have stand ups, daily calls etc which provide some of this integration but nothing really beats that level of communication, understanding, and empathy you share when working together constantly towards a common goal. Given that the number one problem for remote workers is isolation, delaying team building and integration for the purposes of an "onboarding" style project is a shame in my opinion and has the potential to hurt relationship forming with other developers. I've often found those very early stages set the tone for future relationships.
Tips
Based on my experiences if I could give a few they would probably be:
Give it time
If everything feels a little overwhelming just give it time to settle, you know what they say about time. If I'd have gone through with serving my notice after just a few months I'd have given up what has turned out to be the best experience of my career.
Consider others
Assume everyone else is having the same kind of issues and concerns as you. Don't assume that they are doing a flawless job and there is no way you could possibly compare to them. If you were all working in the same office this would all be much more noticeable but working remotely can put up a barrier to both the good and bad things that are happening.
Open up
Try and show some personality and be considerate of the impact when writing over IM, email etc. Have empathy with the people you are working with, you are in the best position to understand the issues and problems they face. Embrace any mistakes you make as an opportunity for both you and your team to learn from. Don't try to cover them up, be open about them.
Communicate
I think it's important to engage in as much communication as possible as soon as you can. If you are given an isolated "on-boarding" project then involve as many other people as possible, tell them what you are working on, and ask if they have any input. I know from personal experience it can be easy to find reasons to avoid communication but I also know that everything works out better if you don't. Communication is also one of those things that becomes more difficult each time you put it off. I say this not because I'm an expert but because I still make the same mistake.
The good stuff
It's not all doom and gloom. Lets face it, we are pretty lucky to be able to work remotely. I'm not sure of the exact figures but in my close circle of friends and family the number of people that get to work remotely is very small. If I had to pick a few remote developer perks I'd go with:
Distraction free working
Most of the time I get so much more distraction free time than I used to in an office. It's much easier to ignore an email for a few hours than it is to ignore someone turning up at your desk. The only downside to this is that sometimes distractions at home can be even worse. Kids running into the office, people knocking the front door etc. The positive time far outweighs the negative for me though.
Home office
I love having the freedom to decorate and furnish my work area as I wish. I find it really motivating to have somewhere comfortable and funky to spend eight+ hours per day. ByBox are awesome about providing kit and office stuff. Great kit and a great office also gives you somewhere cool to spend time hacking on open source stuff projects.
Flexibility
One of the biggest positives for me is the flexibilty. It's really awesome to not have to commute, for some it saves an hour plus everyday and allows you to spend that time doing something rewarding, like taking the kids to school. My youngest is 1 and he's at home all day at the moment. It's been really awesome to not miss out on any of his milestones. I got to take a 5 minute break and see him take his first steps, when he's sick I get to check on him and give him a hug.