A day in the life of a first engineering hire

Step into the shoes of our Head of Engineering for a day

It’s 6:30 a.m. on a Tuesday, and you’re woken up by your cat climbing on top of you and demanding breakfast. Once you’ve put some food in her bowl, you check Slack on your phone to make sure nothing is on fire, then set off to get ready for the day — starting with a much-needed cup of coffee.

You add some freshly ground beans to your coffee maker and hit the brew button, not-so-patiently waiting for the instant dopamine hit served in your favorite mug, when the machine makes a weird grinding sound and suddenly stops. You push every button to get it going, but nothing works. Working remotely definitely has its perks, but this is the first time in a while you wish you could be at the office with an unlimited supply of coffee you don’t have to make yourself.

After making do with not one but two bags of Yorkshire Gold, you head upstairs to your home office, which you’ve kept separate from the rest of your living space in your pursuit of the mythical work-life balance. You start going through your email inbox and Slack notifications when your cat reappears and jumps onto your desk. You do your best to pet her with one hand and reply to messages with the other, but she ends up stepping on your keyboard anyway and sending some gibberish to the company-wide general channel.

You’re catching up on the bug you were working on yesterday in preparation for next week’s launch, which is a new onboarding flow for free users. Several users had reported that the app was crashing when they tried to invite new users into their team account. Your product is literally built on the idea of multi-user workspaces, so you spent hours trying to fix the problem ASAP. After putting together a hypothesis for what caused the issue and recording your progress, you shared your notes with the rest of the engineering team and left it overnight.

This morning, you get the best possible news: one of your colleagues picked up where you left off and figured out how to test the fix, and it works! You quickly ship the change and verify it works in the product. You’re eternally grateful to be part of a distributed team with people worldwide so you can sleep instead of working all night.

You open up your pre-launch checklist and run through it for the millionth time. You’ve already made sure the new flow has been hidden in the UI and running behind the scenes for a few weeks so it’s easy to turn on prior to the launch. You’re acutely aware that if you mess up even just one launch, you won’t get another chance to show customers how great the product is. Plus, you’ll have the CEO and everyone from sales, marketing, and product watching — no pressure.

Now, you need to finalize how you'll measure the impact of shipping this new flow. The main goal is to attract new customers and increase product usage overall. You need to make sure all the data is instrumented correctly so you can track these metrics accurately. You remember that you recently defined the events for new signups so the head of finance could create yet another analysis, and you’re able to finish the rest of the instrumentation in half the time.

Feeling immensely satisfied with the past couple of hours of deep work, you check Slack again to get caught up with the rest of the team. Everyone at the company has been testing the new onboarding for free users to make sure they can get their accounts set up. So far, so good, but you still decide to test the flow yourself for the millionth time — only to quickly run into a scenario where the new onboarding just doesn’t work.

Apparently, existing customers whose free trials expired can’t get back into the product to try it again, even though you recently expanded the free plan. Even worse, when a user can’t complete the onboarding process, they can’t contact you to ask for help because your support system is inside the product.

For a second, you’re relieved that you caught this before next week’s scheduled launch, then shake it off and go into problem-solving mode. You ping the rest of your team and the head of product and set up an instant room via Zoom so you can start fixing this bug. You share your screen to show everyone the problem, and a few other engineers jump on it to figure out the cause and fix it.

In the meantime, you and the head of product get together to figure out how to improve your process for shipping code. “If we had just one extra step, we probably could have caught this issue before you even noticed it,” they say. You agree to add a new ghost inspector test that will run new features under various user conditions every 30 minutes. Your team reports that they’ve fixed the bug, tested it a handful of times, and shipped the change. Another crisis averted.

You debate taking an actual lunch break or just heating up some random leftovers and eating at your desk when one of your teammates Slacks you about an issue that was supposed to be fixed last week. You resign yourself to scarfing down the rest of last night’s dinner straight from the Tupperware before getting back to work.

When the customer first reported this problem, it seemed simple enough. Their dashboard took way too long to load, and your colleague who wrote the ticket figured it would be an easy fix and handed it off to an engineer new to the codebase. They went with the most straightforward approach: to speed up the loading time, they capped the data returned to the dashboard to the last 100 queries. Problem solved! The customer was happy, and everyone moved on.

But yesterday, you got reports of a seemingly unrelated bug where customer data suddenly became “disconnected.” You dig into the issue further and finally discover what happened: that “simple” fix interrupted all the historical data. When the queries couldn’t return any results, they’d just disconnect. It would probably take a month to make it work, but you can’t afford to spend all that time fixing one small piece of functionality requested by a single customer.

Now you have the unfortunate job of telling the customer that you need to remove the fix, and it’s unlikely you’ll ever get it to work. Thankfully, the customer is pretty understanding that you have to make difficult decisions like this, but you still feel bad about disappointing them. As if she could sense your mood, your cat comes into your office and meows until you scoop her up. You scratch her behind the ears until she’s purring like an engine in your lap — it never fails to help you unwind and refocus.

You turn back to your computer and see a Slack DM from the head of marketing. They’ve been working to finalize all the content for the launch, and they want your input on some things to make sure what they wrote is correct. You’re in desperate need of a mental break from all the code you’ve been working on, so you tell them to send over everything they have.

You end up spending much longer than expected reading through the launch email, LinkedIn post, and tweet thread, but you’re glad you read everything so thoroughly. You spot a few issues and ping the head of marketing about getting on a call to go over everything.

“This section in the email isn’t completely wrong, but that’s not technically how the onboarding flow was built,” you explain. “I think you should rewrite this part or maybe leave it out entirely?”

“If I take that part out, then the metaphor I use throughout the email won’t make sense anymore,” they say.

You don’t tell them that you completely missed the metaphor and offer some alternative ways of describing the new feature instead. They take your feedback in stride and promise to share the updated versions with you before the launch for one last accuracy check.

It’s already well past 5 p.m. by the time you jump off Zoom, and you’re considering wrapping up for the day while checking for any last-minute Slack notifications. You spot a message from the head of finance earlier today, asking if you can take a “quick look” at an analysis that keeps running into errors. You skim through the SQL queries and spot the issue right away: their analysis is completely different from the original business logic in the app.

They’re still online, so you DM them to see if they’re free to talk on Zoom for a bit. They explain how they originally created the analysis to report on ARR for customers per product. It turns out that because they didn’t have the engineering resources to properly instrument the data, they ended up working backward to recreate everything using the raw invoice data.

“Uh, well, there’s a pretty complex business logic written in the app to calculate how much to charge customers based on usage, like discounting them if they change their subscription,” you try to explain. You wish you could have collaborated with them on this in the first place to avoid running into this issue months down the line when there’s so much more data to work through.

“I need to jump off soon for another meeting, but can we work through this tomorrow?” they ask. “I really need to get this analysis working by the end of the week so it’s ready for our metrics review.”

“Sure! I’m happy to help,” you respond, doing your best to look enthused. You know it’ll probably end up taking more than just one day since you practically have to start from scratch. Well, sounds like a problem for future you.