I read a lot relating to remote work and the perceived benefits and drawbacks from a wide range of sources. It’s a subject that I am quite passionate about as I have been a remote employee for over 10 years. I currently run a fully remote development team at Open Energy Market that spans many time zones. My team is small but spread across the UK, US and Europe.
This gives me quite a balanced perspective of the pros and cons relating to remote employees and teams. I will spend the next two posts sharing some views from both perspectives.
In this post, I will start with views, tips and experiences as a remote employee.
How did I end up as a remote employee? Ten years ago I worked for a small SaaS company in central London with an architect based in York. We were the only two developers building out the MVP. After a couple of months travelling 3 hours a day, I decided to ask if it would be possible to work some days from home. I spent all my time talking with the chap in York so was not tied to the office. They said yes but if it didn’t work out then I would be back to being office based.
If you have ever had to use the Central Line in London day in day out you would find a way to ensure that it worked out.
I actually ended up pretty much fully remote right away. It wasn’t such a big deal for the company as they had experience of the architect being remote. The issue, for them, was me proving that I could deliver while not under constant supervision. Delivering I was. We completed the MVP ahead of schedule while maintaining their existing systems. Even as we grew the company from 4 to over 30 and the development team to 10 I remained remote. We also allowed other developers to work remote. Interestingly there was a number who were not interested and preferred the office. They didn’t seem to be able to focus on work while at home and found they needed more human contact.
This is a key point. No matter how much you would like to be a remote employee, it is not for everyone.
Right from the start, I took remote working seriously. I had a young family but still kept the same hours I would at the office. I had wanted to work remotely to improve my work-life balance. By doing this I gained 3 hours a day and reduce my outgoings considerably. So I built a routine that mimicked the one I would have worked in an office. This is key to you achieving when working at home. You can not roll out of bed and sit there in your PJ’s. That does not lead you to be in a productive mindset let alone set you up for good video calls. My routine was simpl. Get up, get showered and dressed in the same clothes I would normally work in. Have breakfast, take my son to school and sit down for 8:30. I would normally work through till 5:30 and then turn off my work PC and switch to “home” mode.
Due to this routine, my productivity increased significantly. There are many articles about the ability to focus that remote employees enjoy. Developer’s need to focus and research has recorded improvements of 50% - 70%. What we do is long, involved problem solving and is not suited to frequent interruption. This is also true of many “creative” types of job. Group interaction is always important to any team. However, when launching a small start up its whats delivered that makes the difference and helps to build a viable company. One key statistic for anyone eploying developers is that on average it takes 15 mnutes for a developer to regain their flow once interupted.
I’ve always made it a priority to interact with the teams I work with. Over the years I have used all forms of chat tools and video conferencing applications. From MSN Messenger to Lync, from Skype to Slack, I have used them all. Whatever the team is using I make it a priority to answer queries promptly and to interact on a social level daily. This helps with team bonding and builds trust that you are present and working. I also keep a well maintain shared calendar and update my online status obsessively. This helps people understand what I am doing at any given time which also helps build trust as I am not visible. Do not rely on email as it is a slow mechanism for interaction. Some will say that the constant alerts in a chat tool will be detrimental. I can understand that but I found that I can at least acknowledge a question without losing focus.
The drawbacks? There are some but in my experience, I have found the causes are down to other people. My family see me at home and so want to interact. My office based co-workers do not see me in the office and so do not always interact. The solution with my family was headphones. I have always had music playing when I work and so the rule is if I have headphones in I am not to be disturbed. My son was about 3 when I started which confused him no end that I was home. I made a point during his primary years to always take and pick him up from school. That way we could get some interaction during the day but he soon understood the headphone rule. The solution with the office-based co-workers is to make a real effort to interact with them. Call them up just to say hi, interact with them on social media. It works and is not really any different to seeing anyone by the phantom “water cooler”. These conversations still trigger great ideas and provide a way to share information.
The other, main drawback is actually maintaining the routine. While there are always occasions to work late, that can not and should not be the norm. When you work from home, it becomes quite hard to detach from work mode at 5:30. That took some learning.
My experience has been all with small, growing, teams. I have always been a full-time employee and not a contractor and so my experiences might be different to others. If you’d like to discuss working remotely or have questions please contact me via twitter.
I have read some articles recently covering the merits of documenting your work days. It’s interesting that this is something that appears to be taking off. I have been doing it for over 10 years.
Why did I start? I don’t know! It started around the time I worked for my first startup. The change from working on a big team to the chaos of a tiny startup was the main reason I would imagine. I was working on so many things I needed a way to gain closure at the end of the day.
Is it beneficial? Yes! I find it helps me to clear my mind at the end of the day. I can restart the next day knowing exactly where I was. It makes me think about what I have achieved and what I still need to work on. When coding it allows me to remind myself between sessions why I have done what I have done. It also allows me to document things that have failed during the day. I may come back to some code much later on and I get to look back and find why I approached it in the way that I did.
It also comes in handy when things go wrong or are questioned. Over the years my Work Diary has come to the rescue many times. Recently a set of Git merges seemed to have gone wrong. I was able to look back to when the issues occurred and see what the main problem was. When my senior developer asked how I figured it out, I told her about my Work Diary.
I actually write my Work Diary throughout the day now and have done for some time. I find it more productive than writing it all in one go at the end of the day. I use Evernote at present and have done since it came out. I don’t actually think it’s that good anymore but have been too busy to switch. I like the decentralised approach and find the ability to search as key. I do not have any fancy templates I just use a standard bullet list of points under a date heading. I keep one note for each month and have them all grouped in one notebook, tagged.
I am quite interested in some of the approaches I have read of late. There seems to be a trend in keeping a journal in Git. Some people have gone so far as hosting their journals in a public repo.
However you decide to journal your work day, I guarantee that you find it beneficial over time.
Not a blog title I ever thought I would write but it is true. I have joined a gym. Actually, I have been going for over a month and a half. This is a massive thing for me. If I am completely honest it is something I should have done years ago. The thought of joining a gym frightened me. I have been a strict veterinarian for 20 years but my weight has always been an issue. Over the last few years as my son has got older and I get to do fewer activities with him my weight has done nothing but go up. I also noticed that I was starting to feel a bit burned out.
I tried home based exercise. I have done Yoga on and off through the years but that wasn’t going to cut it. I bought a spinning bike but in a cold dark shed, it is no fun. I also tried T 25 which was OK. That ended through injury and of all the things to injure, it was my thumb. Don’t ask!
So my son and a friend wanted to join the gym and I took him along for his induction. It was at the local sports centre and it was nothing like I’d feared for all these years. There were normal people (you know the ones without muscles) of all shapes and sizes. There was a range of ages as well with some members well into their 70’s and 80’s (who would beat me in any given task). Surprised I ended up talking to one of the staff who didn’t sell it to me at all. In fact, her pitch was underwhelming and it worked. She asked what I would want to achieve and how much time I could spare a week. I signed up a month later and have been averaging 5 or 6 workouts a week since. The funny thing is that after the first trip my fear turned into total enjoyment.
Now I am not someone that pushes their hobby’s or beliefs down everyone else’s necks. Yet, from a developers point of view, Gyms are well suited to them. You do not have to be social and it’s all about the data. I have an app which that’s hooked up to the gym machines and Google Fit. I track everything and have started to build an analytics dashboard about most of my life. The approach to self-improvement is like continuous learning that many developers follow.
Above all else, though it’s nothing to do with my physical state. The biggest improvement by far is the improvement to my mental state. I can focus for longer and I feel sharper. No matter how many hours I have been working I no longer have slow periods where I am fighting to keep going.
Automated deployments are the expected way to go these days for good reason. The approach of automating everything has long run through the development profession. Books such as the Pragmatic Programmer drum home the issue and providing the reasons why. All hosted platforms provide a mechanism for automation and you should take advantage. No matter what size your project is.
We have used standard Git (Bitbucket) deployments with Azure since our inception. We’ve never had any issues until this week when we had to handle a difference between the Production and Staging environments.
A developer deployed an HTTP Rewrite rule to the Staging environment that should only be deployed to Production. The developer had assumed that as there were some configuration specific web.configs that they were tied to the deployments. This is not the case. When you set up the automatic deployments via Bitbucket or Github you end up having a .deployment file in your repo root directory. This file provides some settings for Azure to honour. The configuration dependent web.configs actually relate to when we had our own in-house developed script to perform releases. Proof if ever there was any that cleaning up your projects as you go is key to minimising confusion (broken windows).
Anyway, I digress. After some research, a recent addition to Azure is the ability to specify the same contents that are included in the default .deployment file as App Settings on your App Services. Now, this is not ideal but it is better than finding a way to script differences within a static file. Full details can be read here.
The premise is very simple. If you have a line in your .deployment file such as
The left-hand side of the = side becomes the App Setting Key contents while the right-hand side becomes the App Setting Value contents. (The = character is not required). This allows you to tailor your deployments to a specific build configuration.
The only downside to this approach is that you end up having to apply the deployment settings per App Service. However, as you would be scripting the creation and setup of your App Services this won’t be a problem, will it?
Some Antergos users have been reporting the following (or very simular) issue this weekend:
error: antergos-keyring: signature from "Antergos Build Server (Automated Package Build System) <admin@antergos.org>" is unknown trust
This can easily be cured with a little pacman based house keeping. The package cache needs to be cleaned up and a refresh of the pacman keys needs to be made.
Welcome to my site and blog. You can find out about me and read my thoughts on code and technology, start-ups and building things.
