How I Structure My Remote Software Engineering Workday
At AdHawk, we have a strong, remote-first culture on our Product team. Out of 13 Software Engineers, we have 9 folks who work remotely outside of our New York City HQ. These engineers work in every major US timezone, from California to Georgia to Delaware. While I’ve learned a copious amount of trivia about the First State thanks to my colleague Pat, I think there are even better highlights to having a remote team in engineering.
We love our remote work culture and have found it fits incredibly well with the functional domain of software development. Remote work allows deep focused periods of work and a quieter, often private office environment that’s helpful for writing quality code and debugging.
Research has shown repeatedly that programmers need fewer distractions and interruptions in order to accomplish their focused tasks, which remote work naturally allows. One study by Game Developer magazine showed that “a programmer takes 10–15 minutes to start editing code after resuming work from an interruption.”
Since I get asked this question regularly by my non-remote developer friends, I thought I’d lay out how I tend to structure my average remote work day as a Software Engineer at AdHawk. I work from Denver, Colorado, so all of this is in Mountain Time. Hopefully this is insightful for anyone considering working remotely or making a transition in either direction, as an individual or a team.
My Workday
8:00–9:30 am: After walking my dog Pumpkin (she’s a Chihuahua/Pug mix), I bring my coffee and cereal up to my dedicated home office. No commute gives me a solid half hour plus back each way. On occasion I use this 90 minutes to schedule a time the day before to pair with a colleague when I know I’ll have a midday workout and thus fewer 1–3 hour blocks in my day for collaboration.
9:30–10:00 am: Standup! I share my notes and hear other engineers’ daily work updates. Currently, all web engineers (7), both iOS engineers, both designers and both product managers all meet in one daily standup meeting. We do video meetings M/W/F, and asynchronous Slack standups on Tu/Th. Async standups use the Slackbot Standuply, which is a recent approach for us. It works incredibly well to let my focused work get broken up less.
10:00–12:00 pm: Another block for focused work. Quite commonly, standup will be a great jumping off point into a smaller group or paired meeting as needed with or without designers and PMs. Usually the follow up meetings are short, 20–30 minute sessions as needed to cover deeper topics that don’t suit standup with the larger engineering group. Often, I’m also helping someone after standup who mentioned a blocker I know I can help solve, or I jump on with someone who can help me when I’m blocked myself.
12:00–1:00 pm: On Tuesdays and Thursdays, I work out over lunch at a spin (indoor cycling) class. The gym is less than a mile from my house and the class is 45 minutes, so I do this and eat lunch at my desk after returning to work. It’s a nice way to get a workout in before the evening, and also split up my work day. I’ll either consciously or subconsciously be thinking through my latest work throughout an adrenaline-inducing activity.
If I’m not exercising over lunch, I’m cooking or cobbling together lunch and taking a quick break. Sometimes I have lunch with my husband Jim who also works from home three days a week and socialize. This time to relax and let my mind wander often helps me sort out tougher coding issues that I’m stuck on by letting a solution bubble up in an unrelated activity.
1:00–3:00 pm: Another solid block for focused work, after taking Pumpkin out of course. The dog gets me outside regularly, which is a great break from staying inside all day working from home, especially in the winter. If I’m pairing with someone, I tend to schedule it down, given how much our team has grown. It helps to more solidly commit to pairing with busy colleagues (including me) pulled in multiple directions. Double pomodoro blocks help too — breaks of roughly 10 minutes every 50 minutes. I have a small timer at my desk to help keep me on track.
3:00–3:30 pm: On Thursdays, we have virtual happy hour! Any engineers available tend to join, regardless of whether they’re imbibing any alcohol. We have colleagues in New York join too, and for us remote employees, it’s a nice way to fit in chitchat and banter that we don’t get to do as easily.
It helps to know personal details about my colleagues lives and build trust given the close-knit nature of a small tech team that collaborates and shares feedback daily on each others’ code. Since we aren’t sitting next our coworkers, I enjoy the chance at virtual beers to talk and catch up about the week and our relationships and life events, and often get to know a newer colleague before I meet them in New York in person.
3:30–6:00 pm: Whether it’s virtual beers or another quick design review, project sync, or occasional company-wide meeting, I often jump out of an afternoon meeting and in with another colleague for a round of solo work. My day ends anywhere between 5 and generally 7 pm my time. If I’ve had another errand during the day (as I often did during a year of wedding planning), I’ll work on the later side. This gives me time for focused solo work or paired work with any night owl east coast colleagues (looking at you, Ian). West coast folks also are usually working still by early evening my time so it’s a good time to collaborate with them. I also find a good stopping point or break is walking my dog sometime between 5 and 6 pm.
How does this compare to working in office?
Overall, having worked multiple office jobs prior to AdHawk, I know working from home suits my work style and my output in software development better. As a group, AdHawk remote engineers have had the fun experience of regularly returning to our New York City HQ office every quarter for a full week, so we also test out the work culture of coding out of the HQ office. This face-to-face time is essential for establishing a baseline for a remote software team and naturally allows for longer conversations and deeper relationship-building with colleagues over meals and activities.
We have an amazing office in New York which I always love seeing and working out of. It’s a converted former art gallery in Chelsea, and near the High Line, plenty of restaurants, nightlife and more. For remote employees, it’s not a perfect side-by-side comparison working from here since we’re cramming our socializing, team bonding events, company lunches and dinners, and collaborating in person with all our colleagues into this one week each quarter. It’s definitely not an average work week simulating what living and working in New York would be like.
While I love my time in New York, I am more productive with my development tasks at home in Denver. I’ve done this for 2.5 years, and working from home I get work done at a much faster pace. Yes, there’s less of a social outlet, and we don’t get to easily go out to a restaurant or quick lunch with a colleague like we do in Manhattan back at HQ. But given the right supporting environment, I find myself leaning deeply into engineering challenges and able to plow through my task list in Jira much more efficiently. There are fewer distractions in my home office, but the onus is on me to make sure I get the exercise, meals, outdoor time and socializing that I need daily.
What about meetings?
We have a pretty low meeting cadence as you might notice from the schedule above. The real anchor meeting to structure my day around is standup. Given that it’s now asynchronous (updates posted in Slack) on Tuesdays and Thursdays, I really have a blank canvas for deciding how to structure my day. It’s taken me a while to figure out what schedule works best! This day-to-day flow continues to evolve as our team gets bigger, we juggle more projects, and our product roadmap changes.
What about pairing remotely?
Have no fear! Pairing remotely on a regular basis has been fun, easy to do, and offers all the same benefits as sitting next to your colleague in person. We do a couple of things to make pairing easy to access, and have tried just about every video software out there. Most importantly, both programmers should be on a solid internet connection, and Google Hangouts/Meet will generally work well.
Slack now has a video call feature, and it tends to work well and allows the watching participant to draw on the screen which can help with paired coding. It’s definitely the least overhead for reaching someone since we are a Slack team and engineering rarely uses email.
Backup pairing solutions I like are Skype, Discord (the best audio, hands down) and Teamviewer. Teamviewer is the best for remote control screen sharing software that’s platform-agnostic (yay Linux!) and smooth when doing remote control. If audio on Teamviewer poses any trouble, we use Discord for audio alongside Teamviewer. For audio issues on any of these, check the settings and ensure that all the inputs/outputs are dialed right — echoes are the worst. Generally, a simple screenshare like Google Hangouts/Meet works well enough though.
Come join us!
Hopefully this has been a helpful overview of what remote work at AdHawk is like. Drop me a line if you’re curious about working at AdHawk or want to chat in general about remote work or software engineering. If this sounds appealing, we’re hiring engineers and would love to chat with you!
