After working in the Bay Area for many years, I decided that being able to afford a house was something I’d like to do. That and family led me back to the East Coast and a new chapter of my career began: Remote Software Engineering.
Transitioning to working remotely in any profession has its challenges. After a few years as a remote software engineer, I have learned many things that don’t work and a few that do. Most of the things that didn’t work helped point me in the direction to those that do and hopefully these bits of insight can help others. These tips are most relevant to someone who is the only or one of few remote engineers on their team.
The largest and most obvious challenge one will face as a remote software engineer is a lack of presence. In an office, people can have small side conversations, ask about one another’s weekends, or simply say “hello” in the hallway. While seemingly inconsequential, these tiny interactions establish presence.
Maintaining presence is important if an engineer is a member of a team or has many stakeholders in their work. Presence can make the difference between being perceived as “a member of team” as opposed to “that one person who works on… What is it they do again?”. The former helps a person feel unified with the team they work for, the mission they are striving towards, and the product they are building; the latter is hollow and temporary.
So how does a remote software engineer maintain presence? With consistent yet relevant communication. Whether a company uses Hipchat, Slack, Google Hangouts, or another chat application, instant communication should already be baked into an organization’s workflow and can be utilized to establish presence. While over-communication is rarely valuable, sending short and well constructed messages about current progress or next steps helps keep team members informed and questions answered.
If instant messaging isn’t on the menu, status emails might do well in its place. There is nothing worse than an employer, manager, or team lead thinking that a remote software engineer isn’t delivering what they should. A single daily email can help provide visibility. The email doesn’t need to be very verbose. It can be as simple as a list of what’s been done today, any blockers that have been encountered, or an update to a nearing deadline. It might seem tedious or unnecessary but, to a manager or stakeholder, such an email can help reassure them of progress and collaboration.
Since communication is so important for a remote software engineer, the tone in which that communication is even more important. Tone is incredibly hard to convey over text communication. Because of this, it might take a few tries to accurately convey negative messages without sounding like an extremely irritated or otherwise nasty individual.
Code reviews are a great example of how the right tone can make all the
difference. Think of code reviews in the recent past, unless a team goes out of their way to be super
positive, most code review comments are a little negative. For example, a typical code
review might have comments like: “This doesn’t look right”, _“Change
Utilizing a positive tone in code reviews and other communication help remind people that their remote team member is just that: a valuable member of the team, invested in their work and the happiness of their colleagues. To enable this perception, the remote software engineer can find opportunities for positivity that might be easily overlooked. Simple comments on how a method’s signature is nicely defined or a code comment is especially helpful are easy things to point out during a code review that express positivity.
For those remote software engineers in the same timezone as the rest of their team, availability shouldn’t be an issue. For everyone else, there may be times in which “after hours” communication can help boost one’s reputation as being dependable and invested despite being remote.
Responding in off hours is not the same as being always available. People need and benefit from downtime and the remote engineer is no different. Because of this, the availability of a remote employee should be flexible but not unreasonable. Responding to a few emails or chat messages after hours or during a morning coffee before their “normal work day” can go a long way. After all, if a company is willing to be flexible and work with a remote software engineer, shouldn’t that engineer also be flexible?