Day in the Life of a Software Engineer
Three software engineers wrote down everything they did on one ordinary workday. No interviews, no prompts. Just the day as it happened.
These characters are composites, built from dozens of real accounts, interviews, and community threads. The people aren't real. The experiences are.
What you'll learn
- A specific day in three engineers' working lives, broken down hour by hour
- How much of a software engineer's day is actually spent writing code (less than you think)
- What the job feels like from the inside on a normal, unremarkable day
Sasha's Tuesday
Alarm goes off. I live in a studio apartment in Bushwick. The apartment is 340 square feet. My desk is three feet from my bed. On remote days this is depressing. Today is an office day so I'm getting on the L train to Union Square. I make coffee in my Aeropress, which takes exactly four minutes and is the most engineering-like thing I do before 9 AM. Toast with peanut butter. Backpack. Door.
L train. I read Slack on my phone because I can't help it. There's a thread from overnight where Victor, a senior engineer on my team, pushed a fix for a rendering issue on our homepage carousel. The carousel has been broken on Firefox for a week and nobody noticed because we all use Chrome. Victor noticed because Victor tests everything in Firefox, Safari, and Chrome, in that order, because he's methodical in a way I aspire to be. The fix is four lines of CSS. The thread is 23 messages long because three people had opinions about the approach.
Office. The media company occupies two floors of a building near Union Square. Engineering is on the 8th floor. I sit in a cluster of four desks with the rest of the frontend team. My monitor is a 27-inch Dell that the company provided. The keyboard is my own, a mechanical one that I bought after my bootcamp because someone told me it would make me type faster. It didn't, but the click sound makes me feel more productive, which is probably worth the $89.
Standup. Our team does standup in a huddle by the whiteboard. Eight people. It's supposed to take 10 minutes. Today it takes 17 because our PM, Rahul, wants to discuss a priority change. We were supposed to be working on the article template refactor this sprint. Now the marketing team wants a new homepage module for a campaign launching next week. Rahul asks if we can fit both. Victor says "no" without elaborating. I admire the confidence. My tech lead Moira says "let's do the homepage module this week and push the refactor." I say "still working on the article template refactor" for the third day in a row, which is true and also makes me feel slow.
Back to my desk. The article template refactor. Here's what I'm doing: our article pages currently render the headline, byline, body text, and related articles using a single React component that's about 600 lines long. It handles everything: text formatting, image loading, ad placement, newsletter signup widgets, and the related articles grid at the bottom. My job is to break it into smaller components. Headline component. Byline component. Body component. Ad slot component. Each one self-contained, testable, reusable. In theory this is straightforward. In practice, the 600-line component has internal state that's shared between sections, and pulling pieces apart without breaking anything requires understanding all the dependencies. I've been reading this component for three days. I understand maybe 70% of it.
Stuck on a CSS grid issue in the related articles component. The grid should show 4 cards in a 2x2 layout on desktop and stack vertically on mobile. It does that. But when an article card has a long headline, the card height expands and pushes the adjacent card down, so the grid becomes uneven. I try align-items: stretch. Doesn't work. I try a fixed min-height. Works on the current articles but will break if headlines get even longer. I Slack Victor. He comes over, looks at my screen for about 15 seconds, and says "use grid-template-rows: masonry. Firefox supports it. For Chrome, set a max-height on the headline and add text-overflow: ellipsis." He walks away. I implement it. It works. That interaction took maybe 90 seconds and saved me an hour. Sitting near Victor is the best thing about this job.
Lunch. I eat at my desk. A salad from Sweetgreen that cost $16.50, which I think about every time I eat it. While eating, I review a pull request from another junior engineer, Amara. She's building the newsletter signup widget. Her code is clean but she's using an inline style for the button border-radius instead of using the design system's button component. I leave a comment: "Could we use the DS button here? It handles the border-radius and the hover state." I rewrite the comment three times before posting because I don't want to sound condescending. She's been here two months longer than me. Tone in code reviews is a skill nobody teaches you.
Design review for the new homepage module. The entire frontend team, plus Rahul, plus two designers. One of the designers, Iris, presents mockups. The module shows "trending" articles based on real-time traffic. Iris's design has a sparkline chart next to each article showing traffic over the last 24 hours. Victor asks where the traffic data comes from. Rahul says "the analytics API." Victor asks if the analytics API can serve per-article traffic in real-time. Nobody in the room knows. Rahul says he'll find out. The design review moves on without resolving the core technical question. I ask one question: "Do we want to lazy-load the sparklines or render them on page load?" Moira says good question. Iris says she doesn't have a strong opinion. Nobody answers the question. I don't talk for the remaining 40 minutes.
Back to the refactor. I've successfully extracted the Headline and Byline components. They render correctly in isolation. I write unit tests for both: does the headline render the correct text, does the byline show the author name and publication date, does it handle a missing author gracefully. The tests pass. I feel good. Then I re-integrate them into the main article template and the spacing between the headline and the byline is 8 pixels too much because the old component had a negative margin hack that I removed when I extracted it. I spend 25 minutes figuring out why the negative margin was there. It was compensating for a padding issue in a parent component that I'm not supposed to touch because it's used on 14 other pages. I add the negative margin back. I write a comment in the code: "This margin compensates for padding in ArticleLayout. Do not remove without checking all 14 dependent pages." This is not elegant. It is real.
I open a pull request with the Headline and Byline components extracted. The PR description is longer than the code changes: I explain what I did, why I did it, what's left to extract, and the negative margin situation. Victor will review it tomorrow. I refresh the PR page twice to make sure the CI pipeline passes. It does. Small victory. I update my Jira ticket.
Leave the office. L train home. I call my mom on the subway. She asks how work was. I say, "I split a big file into smaller files." She says, "That sounds organized." It was. That was the whole day. Two components, a CSS fix I didn't figure out on my own, a design review where I asked one question, and a negative margin I couldn't remove. That's software engineering on a Tuesday when nothing goes wrong. Nobody tells you how much of the job is this: small, careful, unglamorous progress on a thing most people will never notice.
Gil's Wednesday
Wake up without an alarm. I've been waking up between 6:40 and 7:00 for about three years now. My body has decided this is the time. I make pour-over coffee in the kitchen of our apartment in Logan Square. Hario V60, medium-dark roast from a roaster on Milwaukee Avenue. The pour-over takes about four minutes. During those four minutes, I open my laptop on the kitchen counter and check if any PRs came in overnight from our Lisbon team.
There's one PR from Mateo, a mid-level engineer in Lisbon. He's working on the order routing algorithm. When a customer places an order, the system needs to figure out which warehouse to ship from based on proximity, inventory availability, and shipping cost. Mateo's PR adds a new constraint: if a warehouse is at more than 90% capacity, deprioritize it in the routing. The logic is correct. But I see a subtle issue. He's checking capacity at the time the order comes in. If 50 orders come in within the same minute, they'll all see the warehouse at, say, 85% capacity, and they'll all route there, potentially pushing it past 90% before the capacity check updates. Classic race condition. He needs to either lock the capacity counter during routing or implement optimistic concurrency with a retry.
I write 6 inline comments on the PR. The first five are specific and technical. The sixth one, about the concurrency issue, I rewrite twice. The first version sounds like I'm lecturing. The second version sounds dismissive. The third version says: "Nice approach. One thing to watch for: if multiple orders hit this check simultaneously, they'll all see the pre-update capacity. Could we add a compare-and-swap on the capacity counter? Happy to pair on this if it would help." I post it. Tone in code reviews matters more at staff level because your comments carry implicit authority. If I write something carelessly, Mateo might interpret it as a command instead of a suggestion.
Shower, get dressed. My wife Ines leaves for work. She's a school social worker. Our daughter Ava is at daycare, which Ines drops off. I eat yogurt and start my actual workday from the home office, which is a corner of the bedroom with a desk, an external monitor, and a shelf of O'Reilly books that I keep for show because I look everything up online.
Standup on Zoom. 12 people across Chicago and Lisbon. I say my update in about 45 seconds: "Reviewed Mateo's routing PR, have some feedback on the concurrency model. Today I'm starting the technical design document for the warehouse allocation feature. No blockers." Standup takes 14 minutes. Two people go long. Our engineering manager, Sadie, redirects them gently. Sadie is good at standups. She has a rule: if your update takes more than a minute, it's a meeting, not a standup item.
Design session for the warehouse allocation feature. This is a new capability the product team wants: instead of customers choosing which warehouse fulfills their order, the system allocates inventory across warehouses proactively based on demand forecasting. It's a big project. The PM, Bex, has a 12-page PRD. The ML engineer, Tomoko, has a demand prediction model that's 78% accurate on historical data. My job today is to figure out the system design: how does the prediction model feed into the allocation engine, how do we handle the gap between predicted demand and actual orders, and what happens when the model is wrong?
The session is me, Tomoko, Bex, and Sadie. It runs 90 minutes. By the end, we've agreed on an architecture: Tomoko's model generates daily allocation recommendations, the system pre-positions inventory overnight, and a fallback routing layer handles same-day exceptions when demand deviates from the forecast. I'm responsible for writing the technical design document that spells out the data flow, the API contracts, the failure modes, and the rollout plan. Nobody asked me to write this document. I'm writing it because if we start building without one, we'll waste three weeks discovering requirements we should have discussed upfront. That's the staff engineer value proposition: you do the work nobody asks for that prevents the problems nobody sees yet.
Heads-down writing the design doc. I use Google Docs because our team has standardized on it, even though I'd prefer something with better formatting. The document starts with a problem statement, then system context, then proposed architecture with a diagram I draw in Excalidraw, then data flow, then API specifications, then failure modes and mitigations, then rollout phases, then open questions. I spend about two hours on the first draft. The hardest section is failure modes. What happens if the ML model predicts high demand for warehouse A and low demand for warehouse B, and the opposite occurs? The system needs to handle that gracefully, which means the fallback routing needs to be fast enough to reroute in real-time. I flag this as an open question and note that we need latency benchmarks before committing to the architecture.
Lunch. I heat up leftover lentil soup and eat at my desk while reading Hacker News. There's a post about a company that replaced their entire ML pipeline with a series of SQL queries and got better results. I send it to Tomoko with the message "not saying we should do this, but it made me laugh." She sends back a crying emoji and the words "it's always SQL."
Mateo responds to my PR comments. He agrees with the concurrency concern and says he'll implement the compare-and-swap approach. He asks if I have time to pair on it. I check my calendar. I have a 1-on-1 with Sadie at 3 but otherwise I'm open. We jump on a Zoom call and work through the implementation together. It takes about an hour. Mateo is careful and methodical. He asks good questions. At one point he says "I would not have caught the race condition" and I tell him that I only caught it because I shipped a version of this exact bug at my last company and it caused 200 orders to route to a warehouse that was already full. Experience in engineering is just a catalog of mistakes you've made or witnessed. The more bugs you've seen, the more bugs you can prevent.
1-on-1 with Sadie. She asks how I'm doing. I say fine. She asks about the design doc. I give her the summary. She asks if I need anything. I say no. The 1-on-1 takes 18 minutes. We're both efficient people. Sadie asks one question that sticks: "Are you still learning things here?" I say yes, which is mostly true. The warehouse allocation project is genuinely new territory for me. But the question lands differently at 35 than it would have at 28. At 28, the answer is always yes because everything is new. At 35, learning requires you to seek it out. It doesn't just happen to you anymore.
Continue the design doc. I get through the rollout phases section and draft the open questions list. Seven open questions. I prioritize them and assign owners. Three of them are mine. I schedule a follow-up meeting for Friday to discuss the open questions with the broader team. I share the draft doc in our team's Slack channel with a note: "First draft, feedback welcome, especially on the failure modes section."
Ines calls. Can I pick up Ava from daycare? I can. I close my laptop at 4:35, which is the actual advantage of being senior enough that nobody tracks your hours. I pick up Ava. She's covered in finger paint and holding a drawing of something she says is a cat. It has seven legs. We walk home. On the walk, I think about the latency requirements for the fallback routing system and whether we need a dedicated cache layer. Then Ava points at a dog and yells "PUPPY" and I stop thinking about caches. That transition, from distributed systems to a toddler pointing at a dog, is the best part of my day. Every day.
Preethi's Monday
Open my laptop in my apartment in Uptown. I work remote full-time. The company has an office downtown but my team is distributed across Minneapolis, Denver, and Raleigh, so going in doesn't change much. I make tea, not coffee, because coffee makes me jittery and jittery plus debugging equals bad decisions. First thing I check is PagerDuty. No incidents overnight. Good. Then Slack. There's a message from the support team, timestamped 7:22 AM: "Customer reporting that data export is generating an empty file. Customer: Clearwater Medical Group. They've emailed twice."
I look at the Clearwater Medical Group account in our admin panel. They're a mid-size orthopedic practice in Colorado, about 40 providers. Their admin, a woman named Barb, is trying to export patient appointment data for a compliance report. The export was working fine last week. I check the export service logs. The export job ran, it queried the database, and it returned zero rows. But Clearwater has about 12,000 appointments in the system. Zero rows is wrong.
I pull the exact SQL query the export service ran. The query has a date filter and a timezone conversion. Our database stores all timestamps in UTC. The export converts them to the customer's local timezone for display. Clearwater is in Mountain Time. The conversion uses a timezone offset that's stored in the customer's account settings. I check their settings: timezone is set to "America/Denver" which is correct. But the offset the query used was UTC-6, which is Mountain Daylight Time. Except on the date Barb is querying, November 14th of last year, Colorado was on Mountain Standard Time, which is UTC-7. The query converted all the UTC timestamps using the wrong offset, which shifted them by one hour, which pushed some of them into the next day, which fell outside the date range Barb specified.
But wait, that should only shift the data by one hour, not eliminate it entirely. I look more closely. The date range Barb specified was a single day: November 14th. The query interprets "November 14th" as midnight to midnight. With the wrong timezone offset, the window shifts, and if the query is using a strict less-than instead of less-than-or-equal-to on the end boundary, combined with the one-hour shift, the effective window becomes 23 hours instead of 24. That's still not zero rows. Something else is wrong too.
Deeper. I found it. There's a second bug layered on top of the timezone issue. When the export service builds the query, it applies a "soft delete" filter to exclude deleted appointments. The filter checks a column called deleted_at. If deleted_at is not null, the appointment is excluded. Last month, another engineer on my team ran a data migration that backfilled the deleted_at column for all appointments that had a legacy status of "canceled." The intent was to mark canceled appointments as soft-deleted so they wouldn't appear in the active appointment list. That's correct behavior for the appointment list. But the export is supposed to include all appointments, including canceled ones, because the compliance report needs them. The migration didn't account for the export use case. So all of Clearwater's canceled appointments got a deleted_at timestamp, and the export service filtered them out, and combined with the timezone issue, the remaining appointments fell outside the shifted date window. Two bugs, independent of each other, compounding to produce zero rows.
I fix the timezone issue first: the export service should use the IANA timezone identifier and let the database handle DST transitions instead of passing a fixed offset. That's a six-line fix. I write a test case that specifically covers the November DST transition for Mountain Time. Then I fix the export filter: I add a flag to the export query that includes soft-deleted records when the export type is "compliance." Four more lines. Two more test cases. Total code changes: about 10 lines of application code, 35 lines of tests. I open a pull request. My teammate Kwame reviews it within the hour, asks one clarifying question about the DST test, and approves.
Deploy. I watch the monitoring dashboard for 10 minutes. No errors. I go back to the admin panel and manually trigger an export for Clearwater's November 14th data. The file generates with 847 rows. I email the support team: "Fixed. The export was affected by a timezone conversion error combined with a data migration that excluded canceled appointments. Both issues are resolved. Barb can retry her export." Support sends me a thumbs-up emoji. Nobody outside my team will ever know this happened.
Standup. Our team standup is at 11 because the Denver people are an hour behind and we didn't want it at 8 their time. I say "Fixed the Clearwater export bug, it was a compound issue with timezone handling and soft deletes, PR is merged, deployed, verified." My manager Lin says "nice." That's Lin's highest compliment. Seven letters.
Sprint planning. We're planning the next two-week sprint. I lobby for a tech debt ticket that's been deferred three sprints in a row: refactoring the appointment query layer to handle timezone conversions consistently instead of each service doing it differently. This morning's bug is exactly why we need it. Three services convert timezones three different ways and they will keep producing bugs until we standardize. Lin says "let's see how the sprint goes." I know that means no. It means if we finish everything else early, maybe. We never finish everything else early. The tech debt will get deferred to next sprint, where I'll lobby for it again, and Lin will say "let's see" again. This is the cycle. I've accepted it. Mostly.
Lunch. I heat up dal and rice that I made Sunday. I eat on the couch and watch 15 minutes of a cooking show. The break matters. Remote work means the transition from "work" to "break" is a couch cushion. I've learned that I need to physically leave my desk or my brain doesn't register the break.
Afternoon: I'm working on a new feature. Patient appointment reminders via SMS. The feature itself is straightforward but the implementation touches a regulated system. We're sending health-related information via text message, which means we need to comply with HIPAA. The SMS body can't include specific medical information. It can say "You have an appointment tomorrow at 2:00 PM" but it can't say "You have a dermatology appointment tomorrow" because the specialty is considered PHI. I'm building the template engine that generates compliant SMS messages. The rules are documented in a 14-page compliance guide that our legal team wrote. I've read it twice. I have tabs open to the HHS website and our internal compliance wiki. The code is simple. The rules around the code are not.
1-on-1 with Lin. We talk about the timezone standardization project. Lin agrees it's important. She says Q3 might have room for it. I ask if I can write a proposal document that quantifies the risk, using today's Clearwater bug as a case study. She says yes. I'll write it this week. If I can show that timezone bugs have caused X hours of engineering time and Y customer support tickets over the last 6 months, the argument becomes harder to defer. This is the kind of work that doesn't feel like engineering but is: making the case for work that prevents future work. The code I write today saves me from writing code tomorrow. But I have to convince people with spreadsheets, not with pull requests.
Close my laptop. I go for a walk around Lake Harriet. It's cold, mid-30s, but the sun is out. I call my sister in Dallas. She asks what I did today. I say "I fixed a bug where two things went wrong at the same time and they canceled out into nothing." She says "that sounds like a metaphor." It's not a metaphor. It's two bugs, independent of each other, compounding into zero rows. But she's right that it sounds like one. I think about Barb at Clearwater Medical Group, who just wanted a compliance report and instead got an empty file and had to email support twice. She'll never know it was a timezone offset and a soft delete migration. She'll just know it works now. That's fine. That's the job.
Frequently Asked Questions
What does a software engineer do all day?
A typical day includes a morning standup meeting (10-15 minutes), several hours of focused coding or debugging, code reviews, design discussions, and communication about requirements. Most engineers report that only 2 to 4 hours of a full day involve writing new code. The rest is understanding existing systems, investigating issues, and coordinating with teammates. The balance shifts by seniority: junior engineers code more, while senior engineers spend more time on design, review, and coordination.
Do software engineers work from home?
Many do. Fully remote positions are common at startups and distributed companies. Larger companies often require 2-3 days per week in the office. The experience depends on the company's communication culture and the engineer's preference. Some engineers thrive remotely with fewer interruptions. Others find the isolation challenging, especially junior engineers who benefit from sitting near experienced teammates.