What Senior Software Engineers Actually Do All Day (It's Not Coding)
The junior on your team thinks you spend the day deep in a vim session, refactoring some legacy module into a thing of quiet beauty. Your manager thinks you're "unblocking the team." Your partner thinks you're working. You are doing none of these things. You are in your seventh meeting, watching a product manager re-read a Confluence page you wrote in 2022, and the IDE on your second monitor has been open to the same file since Tuesday. This is what senior software engineers do. The coding is what you fit in between.
There's a particular flavor of disillusionment that hits around year eight. You finally got good at the craft — the part you got into this for — and the reward is that nobody lets you do it anymore. Instead you get handed the soft, squishy, undocumented work of keeping a system of humans running. Below is a fair accounting of where the hours actually go.
The Meeting Layer
A senior engineer's calendar is a layered geological formation. There's the standing weekly with your manager, the standup that should be Slack, the sprint planning that runs forty minutes long because nobody wrote the tickets, the sprint retro where everyone agrees to do better and then doesn't, the architecture review for a team you're tangentially involved with, the cross-team sync about a migration that's been ongoing for two years, and the "quick chat" that becomes a forty-five minute therapy session about a coworker's promo packet.
The work isn't the meetings themselves. The work is the context-switching tax between them. You get fourteen minutes between a 1:1 and a design review. You can't start anything real in fourteen minutes, so you read Slack, refill coffee, and pretend the next meeting will be the one where decisions get made. It won't be.
By Thursday afternoon you've spoken approximately 11,000 words and written about 60 lines of code, half of which you'll delete on Friday morning when you realize you were tired and wrong.
Code Review as a Second Job
Every senior engineer eventually wakes up to the fact that code review is not a side task. It is the job. You are the choke point through which other people's work becomes production code, and if you sit on a PR for three days the entire team's velocity drops.
There are flavors of review, and each one has its own time cost:
- **The junior PR.** Forty changed files, two of which actually needed to change. You leave fourteen comments. You will see six of them addressed and eight ignored, and you'll re-leave the eight ignored ones on the next round.
- **The peer PR.** Someone competent did something reasonable. You skim, you approve, you move on. These take eight minutes and are the only reviews that don't cost you a piece of your soul.
- **The architectural PR.** Someone on another team is doing something that will, in eighteen months, become your problem. You have to either spend two hours writing a careful, diplomatic objection, or rubber-stamp it and start drafting the post-mortem you'll be writing in 2026.
- **The "urgent" PR.** Production is on fire. The fix is obviously wrong but it works. You approve it and create a ticket that will never be prioritized.
The actual mechanics of reading code carefully — running it in your head, checking the test coverage, thinking about what happens at the boundaries — is real intellectual work. It looks, from the outside, like you're scrolling GitHub. Your manager has no idea this is the most cognitively demanding part of your week.
Mentoring, or: Explaining the Same Thing Forever
You will explain idempotency to four different people this quarter. You will explain why we use feature flags, what a circuit breaker is, why we don't deploy on Fridays, why we sometimes do deploy on Fridays, what the difference is between a mock and a stub, and why "it works on my machine" is not a closing argument.
A good chunk of senior-engineer time is spent transferring context that lives only in your head into someone else's head, in real time, on a video call where the other person is also half-watching Slack. You will do this patiently because you remember being the person on the other end of those calls, and because the alternative is doing the work yourself forever.
Mentoring also includes the unbilled emotional labor of telling a junior that their PR isn't ready, then watching them push back, then re-explaining the same point with different words, then eventually pairing on it because words aren't going to do it. By the time the PR merges you could have written it yourself in forty minutes. But then you'd have done it yourself in forty minutes for the rest of your career, and that's not the deal.
The Document That Nobody Will Read
Senior engineers write. A lot. Not code — documents. The design doc for the migration. The post-mortem for the outage. The RFC for the new service boundary. The onboarding doc that gets out of date six weeks after you publish it. The Slack thread that turns into a doc that turns into a ticket that turns into a meeting that turns into a different doc.
Most of these documents will be read by between zero and three people. The post-mortem might get a wider audience, briefly, before being forgotten. The design doc will be skimmed by everyone who comments on it, and only one person — the person who actually has to implement the thing — will read it carefully. They'll find three contradictions on page four.
You write them anyway because the document is the artifact that survives you. When you leave the company, or move to a different team, or get pulled into a different priority, the doc is what's left. Code without context is a liability. The document is the context.
Estimation, Politics, and Other Forms of Lying
At some point a manager will ask you how long something will take. You will say "two weeks" because the real answer — "between three days and four months depending on six things I can't yet evaluate" — is not a useful sentence in a planning meeting. Then you will spend the next two weeks watching the estimate be wrong, in interesting ways, while explaining to stakeholders why the estimate was wrong, in less interesting ways.
You will also be asked to weigh in on cross-team decisions where the technical answer is clear but the political answer is the opposite. You will learn to phrase your objections in language that lets the other team save face. You will learn that "have we considered the failure modes here?" is a complete sentence that does ninety percent of the work of a confrontation, without the confrontation.
This is not coding. This is statecraft with a YAML file.
Q&A: Things Senior Engineers Actually Get Asked
Q: How much do you code in a typical week?
Honestly? Maybe eight to twelve hours of focused work, on a good week. On a bad week, two. The rest is review, meetings, writing, and being interrupted.
Q: Is that a problem?
Depends who you ask. The company probably gets more value from your meetings than your code at this level, because you're a force multiplier. Your soul, however, gets more value from the code.
Q: When do you actually code, then?
Early mornings before the meetings start. Friday afternoons when the calendar dies down. Occasionally a Tuesday where someone cancels three things in a row and you get four contiguous hours and feel briefly, dangerously alive.
Q: Is this what staff engineering is too?
Worse. Less coding, more documents, more strategy, more sitting in rooms where decisions are made. Some staff engineers code three hours a week. Some are happy about it. Some quit and become consultants so they can code again.
Q: Should I take the promotion?
Take it for the money. Don't take it expecting more interesting work. The interesting work is the work you're doing now, with a quieter calendar.
The Part Nobody Tells You
The strange thing about all of this is that the job, despite the meetings and the documents and the diplomacy, is still mostly a good one. You get paid well to think about hard problems. You get to watch juniors become competent and competent engineers become senior. You get to point at a system, eighteen months on, and know that the part that's still standing is the part you fought for in a design review nobody wanted to have.
What gets lost is the simple pleasure of opening an editor on Monday morning and writing code until Friday. That version of the job belongs to a different stage of your career, and the people who tell you they still have it are either lying, working at a three-person startup, or about to be promoted.
The work has changed. It hasn't gotten worse, exactly. It's gotten heavier, and quieter, and more about other people. You spend your days holding up the load-bearing beams of a system most of your coworkers don't know exists. The IDE stays open. The cursor blinks. Somewhere, a calendar invite is being sent.