Samantha Wessel: Day in the Life

Samantha graduated from Codesmith’s West Coast Remote Immersive program in 2019. Here she breaks down a typical work day in her life as a Senior Software Engineer for a media non-profit organization in Washington, USA.

One thing I warn folks who are interested in making a career transition into software development is to get the idea of ‘a coder in a dark room talking to no one’ out of their head. While that may be the reality for some software devs, in my experience, software engineering requires a lot of cross-team coordination and meetings.

As an example, I kept running notes of a pretty typical day for me. I work as a Senior Software Engineer at a media non-profit organization. From what I’ve gathered, my day is similar to other devs at my organization.

9:00 AM     Prep for the Day

• I first check my notes from the previous day. At the end of each day, I write myself a note about where I left off regarding a particular ticket, items I need or want to get done the next day, etc. It helps reorient my brain each morning rather than spending an obscene amount of time trying to remember things before the caffeine has kicked in (yes, that is the obligatory caffeine reference. Take a shot of espresso.)

   

  “My manager and I have bi-weekly 1:1s to sit and talk about any issues I’m running into, any questions I have, and more often than not, just connect on a personal level.”

   

9:15 AM        1:1 With My Manager

• My manager and I have bi-weekly 1:1s. He and I have a good relationship and frequently have unofficial check-ins a few times a week mostly via Slack. This specified time allows for him and me to sit and talk about any issues I’m running into, any questions I have, and more often than not, just connect on a personal level. 

In this particular 1:1, we discuss the status of one of the cross-team projects I’m working on, as well as touch base about the recently ratified Collective Bargaining Unit my Union just ratified.

10:00 AM     Project Meeting

• One of the projects I’m working on involves several teams throughout the organization. When this feature is released, it will require extra work for our users. In my case, my end users are the content producers at the organization. This feature is vital to us and our mission. 

However, rolling out this feature will require training on how to use the new feature as well as messaging to explain why it’s critical. As the lead developer for the project, it may seem strange that I was part of this meeting. However, as the meeting had folks present who would be instrumental in the training, I found it important to be there to make sure that we have everything in place on our side to make the rollout as smooth as possible. 

From this meeting, I realized that it could be beneficial to our users to have an additional hint above an input field to guide them a bit more. Without attending this meeting, I don’t know that the idea would have crossed my mind.

10:30 AM     Address Pull Request (PR) Notes/Slack Chatting

• I submitted a couple of PRs for review the previous day, and my teammate left some comments on them. I take the next 30 minutes to address those comments and re-submit my PRs for review. Also during this time, there is a discussion in the team channel about our new Git & PR Workflows to help make our lives a little bit more sane. I participate in this Slack convo while working on my PRs. And of course, importantly, I discuss in another Slack channel about the latest episode of Great British Bake Off because I have thoughts.
  
  

Samantha's work setup, where much of the day is spent battling with the cat for use of the keyboard

11:00 AM      Team Standup

• One of my favorite parts of my day is my daily team standup. Our team is small and we’re really close. Our scrum is pretty standard (what did you do yesterday, what are you doing today, any blockers) and once again my daily notes to myself come in very handy. Like most days, our scrum quickly goes off the rails as we start talking about random things - today it was how the coffee shop where one of our teammates was working from used to be a mill. As our Senior Product Manager said (lovingly) during one daily scrum, we are the easiest people in the world to take off-track in a conversation.

11:15 AM       Writing Code, finally!

• I’m over two hours into my day and it’s the first opportunity I’ve had to start writing code. We just started a new sprint, so my queue is full of tickets. I know I’ll have more coming following a meeting I’m to have later in the day, so I start a couple of easier tickets. 

I spend the next couple of hours addressing these bug tickets that one of our Test Engineers opened. He and I Slack back and forth about the nature of the bug, and I get some clarification on how to recreate the issue. I wrap these up and submit PRs.

1:15 PM        LUNCH!

"Being a successful engineer requires being able to technically communicate with other developers, as well as working with folks throughout your organization who may not have the same tech savviness as others."

2:30 PM       Cross-Team Meeting

• The other software dev team in our division has a really big release coming in March 2024. My team had a giant release in August 2023 where we sunset our old product and released our new one. With our new product, and the upcoming March release, a lot of integration work between the two products has started. 
• Today’s meeting is to review the proof of concept work for the integration and to get a status update. This is the first time our two teams have worked this closely together, and honestly, I’m really enjoying it. They’re an incredibly smart and fun group. Not only are the devs present, but so are the product managers and designers. During this meeting, we are going through a use case document to help guide us on what work needs to be done next, and what tickets need to be created. The meeting is a mix of high-level discussion and, every now and then, we get into the weeds of the architectural decisions we need to make. When this happens, myself and some of the other devs try to pull us back. We decide to have a dev-only meeting later in the week to have some of these architectural decisions. We feel this makes sense because we’re concerned that the product managers or designers may not fully like what we’re saying. We figure once the devs have met and come up with a plan of attack and software architect decisions, it’ll be easier to get the product managers and designers on board.
  
  
  
  

  "As a developer, you can’t just assume that your day will solely be writing code."

3:30 PM      Create Tickets

• Following the cross-team meeting, I read through my notes and created several tickets for work that needs to get done during this sprint to further the integration project. I assign all of these tickets to myself, since as for now, I’m the tech lead from our team for this integration. After creating these tickets, I send them in a Slack channel for the other team’s devs to review as well as my manager and our product folks.

4:00 PM.     Start Working On the New Tickets

• It’s been a few hours since I’ve been able to write some code. In the last hour of my day, I start working on one of the tickets I just created for the integration. This ticket is critical to get done before work can really begin on any of the other tickets. I start pseudo-coding out my plan of attack and writing my first few methods.

4:50 PM      Write Notes/Start Wrapping Up

• I like to give myself the last 10 minutes to write up my end-of-day notes that I’ll read when I start my day the next morning. I also quickly go through my emails to see if there’s anything I’ll need to respond to. I check the team Slack channels for anything of importance. Then I send a message to my team and sign off for the day.

As you can see, on this day in particular, I didn’t write much code. There are definitely days when I have only one meeting and can focus more on writing code, but I would say there was nothing about today that felt exceptional or overly scheduled.

All this to say, as a developer, you can’t just assume that your day will solely be writing code. 

Being a successful engineer requires being able to technically communicate with other developers, as well as working with folks throughout your organization who may not have the same tech savviness as others. For me, I enjoy this and appreciate getting to work with others.