A remote day in the life of a junior engineer

Written by Julia GrabosSoftware Engineer, Tines

Published on March 4, 2022

This article was posted more than 18 months ago.

While other software companies are returning to offices, Tines is continuing with its contemporary approach to the workday. All engineering positions are optionally remote, with flexible hours while still providing access to office space and high-quality equipment for the home office. To build a strong, tight-knitted team, we regularly meet in person, during company-wide meets and smaller team-wide gatherings, spending plenty of time on both cultivating our culture and product while also remembering to socialize and build connections.

During my normal day-to-day, all work happens remotely, and here’s what my typical day looks like.

Morning 

I begin each day by promptly scanning through Slack and my inbox. Most mornings, there aren’t many tasks to act on, so usually, this just involves catching up on a few threads that I missed from folks in the US time zones. With that, I move to email. I like to subscribe to a few services that send out daily digests, such as Medium, so I don’t have to go out of my way to go looking for reading content. If I spot something that piques my interest, usually in the field of React or Rails or a catchy software engineering-y title, I spend 10-15 minutes reading. Alternatively, I catch up on the never-ending reading list in my Chrome browser, where I append pages I don't have time to read then and there, but are  interesting enough to come back to.

Self education is an essential daily task, and once I’ve done that, it’s time for Github. I review any new PRs that have been opened by my peers, leaving clear constructive feedback on the proposed changes. This task is also sprinkled throughout the rest of my day. It's essential for the team that we all dedicate time to deliver PR reviews in frequent short bursts. Otherwise, it can become very slow to get anything merged. PRs get bigger and bigger when that happens, making them even harder and slower to review.

Our engineering team has a weekly rotation of a daytime on-call responsibility. This role involves monitoring incoming Sentry alerts, filtering and tagging created Github issues, and being the first point of contact when folks from other departments need our engineering expertise. This week I’ve won the prize, and so I dig right into my list of on-call duties. I review the alerts that came in overnight and create issues to track them. Then in Github, I triage and add labels to those issues and others that were opened recently, making it easier to filter when looking for bugs to bash or calculating our stats. Finally, if it’s release week for our on-premises customers, I follow one of our run-books to cut a release and make the file available for download.

Just before lunch, I get a chance to look at my weekly sprint goals. As I’m the nominated on-call for the week, my goals are a little smaller in scope than normal to account for the time I’ll need to spend responding to questions, alerts, and bugs. However, my goals still include interesting product improvements, requiring a mix of backend and frontend changes, as well as improving some automation using Tines. Dogfooding is a big part of working at Tines for many people in both technical and non-technical roles. 

With each goal, I like to dissect it into a small, bite-sized task, often creating an issue with checkboxes for each one. Additionally, some goals may require a tech plan to be written up to better outline the problem statement and potential solutions and shared with the team. This allows me to gain valuable feedback and catch any issues early before I write any code. 

Afternoon 

After lunch, the team joins our daily sync call for between 15 - 20 minutes. We quickly type up our daily updates in Slack using the “Done”, “Doing” & “Discuss” headings and follow up with team-wide discussions on any “Discuss” points raised. This approach has drastically reduced the duration of our daily stand-up while at the same time keeping everyone focused. Maintaining a history of everyone’s updates in a Slack channel can be useful later on in the day, and if a team member is unable to join a sync, they can simply post their updates asynchronously. This call is also an excellent opportunity to get input from the team on any problems and blockers or ask for help in the form of a pair programming session. After today’s sync, I pair up with my colleague to debug an issue in Relay. For this, we use a handy VScode extension called Live Share, which allows me to follow my colleague's cursor in their code editor. To further ease communication we hop into a Google Meets call. We promptly solve the issue together and my colleague is unblocked and able to continue their work. 

Next, it’s time to start digging into the tasks curated before lunch. Today’s first task is to add a new modal. Using some sketches from the design team, I implement the component in React. This skeleton code is added behind a feature flag and pushed to production so that our designers can inspect and make sure that the changes match their expectations. In the meantime, I focus on adding the backend operation that will be triggered by the modal, remembering to also write some unit tests to guard that the code matches specifications. When I’m happy with the progress, I open a PR with the aim of keeping the changes small and digestible for a quick change review. Once reviewed, I merge the changes into the main branch, and the updates are live for our customers within minutes.

Throughout my day, I make an effort to jot down thoughts that I want to mention in the weekly Friday retrospective. These thoughts often involve ideas for areas of improvement that require a team effort and successes worth calling out and celebrating. It’s essential to discuss these in a regular retrospective as they greatly impact the team's ability to develop and aid in resolving any blockers or issues.

As software development is more often than not a sitting job, it’s important to take regular breaks to stretch and walk around. Being a Fitbit user, I get a notification every hour or so reminding me to take 250 steps. While that goal is often ambitious to achieve while working, I  try and act on it at least by having a quick stretch whenever my watch buzzes and remembering to stay hydrated! An afternoon pick-me-up is needed, so I complete my goal of 250 steps on my way downstairs to the coffee machine and satisfy my caffeine addiction all in one go.

Some days I find myself blocked or unable to progress with a task, as I am waiting on feedback from another individual or need help with resolving an issue. At moments like this, I like to turn to “bug-bashing.” In our Github repo, we are very diligent with labeling bugs as either “small” or “large”, indicating the estimated amount of work required to fix the bug. As I wait for some feedback from the design team on a feature flagged change, I look at the oldest “small” bugs and dig right in. This keeps our product relatively bug-free and our customers happy. 

Conclusions 

As the workday winds down to an end, I push any remaining changes I have made and open draft PRs. This is in case I’m absent the following day and my teammates may need to continue my work. Some of the more exciting changes include releasing the code shipped earlier behind a feature flag. With the designer’s ack, I put together a PR removing all feature flags for the new modal and get a quick approval from my colleague. Before the day is out, our customers can enjoy a brand new feature.

Finally, before logging off for the evening, I complete my day-time on-call duties and do another sweep of Sentry alerts, respond to questions and queries in Slack channels and triage Github issues. And then it all kicks off again the next day!

If you're interested in joining our engineering team, we are hiring! Check out our open roles here.

Built by you,
powered by Tines

Already have an account? Log in.