Lessons From Working Remotely as a Software Developer

Farzin Ahmed
Hootsuite Engineering

--

Hootsuite has been moving towards becoming a truly global company and one of the features of that is building asynchronous work environments. Working remotely has many benefits, but unless a team is optimized to work remotely, there needs to be some structure in place to accommodate a remote teammate.

“We like to give people the freedom to work where they want, safe in the knowledge that they have the drive and expertise to perform excellently, whether they at their desk or in their kitchen. Yours truly has never worked out of an office, and never will.” — Sir Richard Branson, Virgin America

Earlier this year, I decided I wanted to work remotely for a week for personal reasons. My team is located in Vancouver and usually does not work remotely for long stretches of time and therefore are not habituated to communicating across long distances and time zones. Under these circumstances, working with a 14 hour time difference proved to be an interesting challenge. Before I left, I took some steps to smooth out the process. Here is what I tried

Pre-plan your work (if you can)

Pick a few tasks from your sprint or backlog that you know you can work on without requiring any intervention and assign them to yourself. For me this was writing API contract tests for Facebook because I am familiar with the Facebook API and have written similar tests for LinkedIn before and because the use cases I needed to test didn’t require any clarification. An example of a bad issue to work on would be a bug, in a codebase you’re not familiar with, where you can’t reproduce the bug. Have enough issues in case you get blocked on one, so you can move on to another one.

Have a designated person to sync with everyday

Have someone in the office to talk to about the issues you’ve worked on and someone who can update you on any changes happening or if you missed discussions that happened face to face. I synced with my team lead who kept me updated on the current status of the sprint and what the team was up to.

Communicate more often

I was unable to make standup because of the time difference. Since I was not in the office, the sprint board was the closest representation of what I was working on. It’s easy to pick a ticket from the sprint board and bury yourself in it until you’re done with the ticket without realizing that the team might not know what you’re working on. It helps the team if you can do a status update when you can on top of updating your designated person. If you’re blocked on an issue, let the team know you’re going to table that issue for now and move on to another issue.

When I returned, we talked about my week of remote work during our sprint retrospective. Here are the lessons we learned from this experience

Have better descriptions on issues

I saw tickets in the sprint board with a one line description that didn’t have enough details to understand what the work required was. Someone working remotely might not have access to people to clarify what the acceptance criteria of an issue is. Flesh out the issue as much as possible with a description, acceptance criteria, ways to reproduce a bug if it is a bug issue. Images and documentation help as well.

If you’re working on a big issue, update issues to show progress

In cases where someone can’t make standup, and rely entirely on the sprint board, it’s hard to tell any progress is being made on an issue if the sprint board does not reflect that. The issue you are working on may be a big one and you may be updating the team during standup but your remote teammate might be in the dark. Update your issue with subtasks or comments so sprint board reflects your current status on the issue

Take minutes on face to face meetings

If you make any decisions while meeting in person, it would be nice to see how those decisions came about so you won’t have to explain the whole thing again when the remote person is back. Also, in case your sync buddy forgot to inform you about it, you would still be informed about the meeting

Overall there were a lot of lessons learned from working remotely. I love the flexibility of working remotely while on vacation. I think it is important enough to continue iterating on the process of becoming better at communicating asynchronously. Do you work remotely? What does your team do to promote a remote working culture? Feel free to share your thoughts in the comments or reach out to me through email.

Farzin Ahmed is a junior software developer on the Engage team at Hootsuite. She is passionate about improving developer productivity and building efficient teams. When she’s not building software, she likes to hike, paint and play the guitar. Connect with her through LinkedIn!

--

--