So I’ve been at Canonical for 6 months now, and after six months into my first full-time remote gig, and while I knew it was going to be different than office work, you never really know how it’s going to play out.  Needless to say, there are some lessons I expected, and some that were new, and it’s worth examining them.

Lesson 1: Find Your Space

I knew that I would have to have a sectioned off room to treat as my office.  You need to have some sort of boundary to separate your home and work life.  I am fortunate enough to have a spare room that we set up, but was just having a room enough?  It turned out that I needed to be smart on how to use the room.  I have a three year old and a ten month old, and they don’t quite understand that I’m working all the time.  So instead, I set up a system that if the door is closed, I am in a meeting and can’t be interrupted.  So far, it’s working alright.  It’s important to have some sort of visual indicator of when and when you can’t be interrupted (and you will be interrupted).  The visual system also helps my wife.  In the end, I still get interruptions, but they are far fewer than what I would get at an office.

 

Lesson 2: Overcommunicate

I knew for remote work that you don’t benefit from the stream of information at the office.  Coffee talk, pre-meeting chit-chat, lunch conversations; you get none of that in a remote job.  I knew I would have to communicate extra when talking to people, but what I didn’t realize was how much I’d have to emphasize asynchronous communication.  Asynchronous communication is all about conveying information when the recipient may be separated from you in space and time.  Here are some things I’ve had to get better at :

• Better commit messages: Inspired by this post, I needed to get better at conveying my information in code commits; especially the why and what I learned along the way.
• Better project tracking: I’m still struggling a bit with this, but I need to be better at proactively writing down what I just learned.  If I just learned something, others could stand to learn from it, and I should write it down in the first place someone would look for it (repo README, teams introductory docs, comment in the code, etc.)
• Oversharing: Give somebody interested in your work everything you can to track it.  Provide links to what you looked at, do code reviews often, write post-mortems and retrospectives pro-actively.  and document what you do.  This helps people come up to speed with what you’re working on, destroys silos, and just makes you a better engineer because you are forced to examine your process and thoughts.

 

Lesson 3: Isolation and Stagnation

This one’s tricky, and not talked about often.  When working alone, remote, you can easily feel like you’re in a silo and not growing.  It’s on you to make sure you find a balance in social affairs to combat this.  I run a Meetup, and going to the Meetup monthly has been a huge help in learning new things and talking tech with people.  Conferences, co-working spaces, even lunches with former co-workers (I try to do this once every month or two, too), all help.   You also need to make sure that you are constantly growing.  It’s easy to miss out on new ideas when you work by yourself; so challenge yourself with coding challenges, MOOCs, Youtube videos, and anything else that can let you learn.

 

 

Most of what I wasn’t expecting with being remote was the isolation of it.  I worked very hard to make sure I had a physical setup for remote, but wasn’t ready for the mental setup.  I’m lucky that I have enough resources to help me out; but beware if you are considering the move yourself.  I can definitely see how remote isn’t for everyone, and you have to take more of your own growth, communication, and social interaction into your own hands when you make the switch.