Spilling the Tea : A Day In the Life of a Software Engineer
TechTogether has helped to define my college experience — after being a 2018 SheHacks participant, I continued as an organizer with TechTogether Boston in 2019 and 2020. I’m excited to come back and share what I’ve been up to since graduation!
I graduated with my Math & Computer Science degree from UC San Diego in the midst of the COVID-19 pandemic — with a fully online spring quarter and Minecraft commencement ceremony, it only seemed fitting that I start my full-time career remotely as well.
I was lucky enough to sign before finishing school, and was excited at the prospect of staying in my home state of California after college. I work at one of the big five tech companies (think one of the FAANGs) in the San Francisco Bay Area.
Since I was onboarded in August of 2020, I’m still the newest (and youngest) engineer on the team.
Each new hire gets an onboarding plan with lists of people to meet, tutorials to complete, and environments to set up. Somewhere between onboarding and meeting everyone, I started delivering during our sprints. There truly is no ‘typical’ day in the life of an engineer, but here’s what one of mine might look like:
8AM
I (usually) try to wake up around 8am! My favorite thing to do in the morning is to take a walk or run around my neighborhood, and sometimes swing by Starbucks to pick up a mobile order. Getting outside helps kick my day off on a positive note.
9AM
I’m usually online around 9am — there aren’t strict hours as to when you have to be online, but folks generally start around 9 or 9:30. I’ll start up my servers and set up my development environments for the day.
10:30AM
My team has a recurring standup at 10:30 every morning. Our work is split up into 2-week sprints, where everyone has tasks to complete. Standup is essentially a check-in for everyone — we go through our Agile board, talk about what we did the day before, what our blockers are, and update each other on the status of different items. It’s important to touch base regularly and communicate any issues you might be having, especially since the team is fully remote right now.
11AM
As an engineer, the work you do is generally very independent. You’re expected to deliver on your tasks that sprint, but as a new grad with no experience in our team’s stack or infrastructure before, I ran into a lot of issues.
How do I start a server? How do I test in this environment? Why is my build failing?
Needless to say, it can get very frustrating very quickly. When that happens, I take a tea break and sometimes a walk.
I’d had internships before, but I’d never worked in a large codebase, so I wasn’t sure what to expect. What I learned at a company as large as mine, is that there’s documentation for everything. There’s documentation of the documentation. There’s documentation for the documentation that doesn’t yet exist. I could go on, but I digress. As a new grad, the wikis and tutorials were truly lifesavers.
Doing your research is always the first step to do in solving a problem. Read the docs. Search the internal forums. Once you’ve exhausted those options and you’re still stuck, reach out to a teammate. I quickly found out that while reaching out for help can be intimidating — after all, you don’t want to waste someone’s time — it’s so important to learn how to ask questions and communicate your issues in a concise, efficient way.
Present your issue. What were you trying to achieve? Which error messages do the logs show? What steps did you take, and what happened?
Most people can’t read your mind — they’re not going to take one look at your screen and give you the answer. In fact, even if they could, they don’t. Part of the job is mentoring younger engineers.
3PM
Days are always different — sometimes I’m in design meetings with our TPM and other engineers, other days I’m left alone to work the entire day. What never changes though, are code reviews (CRs).
Each piece of code pushed to our codebase has to be published and approved by at least two other engineers on the team. Each team has its own set of best practices and development style. Many of my CRs come back with comments on style, efficiency, and general-knowledge tips. It’s my responsibility to review each comment, choose whether or not to accept it, and revise my code.
Getting my code reviewed by someone besides a professor or TA was definitely intimidating at first; however, on a supportive team, feedback is given to make you a better engineer, in the hope that one day you’re able to support the team and bring everyone around you up.
Mistakes will be made, especially when first starting off in a new position. When I pushed a bug to our production server one day, my teammates were surprisingly calm & collected while I anxiously downed my boba at my desk. Don’t let those one off mistakes knock you down, they happen to the best of us. The beauty of using Git, my friends, is that you can roll back changes at will.
Depending on how busy we are, I’ll usually try to wrap things up by 5 or 6pm. Working remotely has definitely made it a challenge to maintain work-life balance, but I like being able to devote time at the end of the day to working out, side projects, and personal hobbies.
Well, that’s it! A day in the life of a full-time software engineer. Despite being thrown into a well-oiled machine of a team, I felt very supported by my teammates, mentors, and managers. I’m excited to see where the next few years take me!
Interested in attending a hackathon and getting access to more articles like this one? Subscribe to TechTogether’s bi-weekly newsletter.
