What Senior Devs Actually Do All Day (It's Not Coding)

May 10, 2026

What Does a Senior Software Engineer Do All Day

Somewhere around year six, you stop being the person who writes the feature and start being the person who explains why the feature in the ticket from Q2 still hasn't shipped. You open your laptop at 8:47, intending to finish the migration script you started yesterday. By 9:03 you're in a Slack huddle about whether a button should say "Submit" or "Continue." By 11:00 you've reviewed four pull requests, none of them yours, and answered the same question about environment variables three times in three different threads. The migration script is exactly where you left it.

This is the job. Not the job description — the actual job. If you're new to the title, or you're a manager wondering why your principal engineer's individual output looks like a junior's, here's a breakdown of where the hours actually go.

The Pull Request Treadmill

Open the dashboard. There are eleven PRs waiting on your review. Two are from contractors in time zones that have already gone home. One is a 2,400-line refactor with the description "small cleanup." One is a single-character fix to a config file that has been sitting there for three days because nobody else feels qualified to approve it. One is from a junior who keeps force-pushing every twenty minutes, so every time you load the diff it's different.

Reviewing code is not the part of the job anyone trained you for. You learned to write code. Reading other people's code, at speed, while inferring intent from variable names like tmpData2_final, is a separate skill that nobody teaches and everyone is expected to have. You develop heuristics. You learn which directories matter and which don't. You learn that the test file is often more revealing than the implementation. You learn that the PR description is a lie, and the linked ticket is a different lie, and the truth is somewhere in the commit history if you have an afternoon to spare.

You also learn, eventually, the dark art of the rubber-stamp approval. You know it's wrong. You do it anyway. The PR has been open for four days, the author is on the critical path, you've read enough of it, the CI is green, and there is a meeting in six minutes. LGTM. Ship it. The shirt practically writes itself.

Meetings That Should Have Been Decisions

You have standup. Then you have a "quick sync" that is not quick. Then you have architecture review, where someone presents a design doc you reviewed last week and the same three people raise the same three objections you already addressed in the comments. Then there's the cross-team alignment meeting, which exists because two PMs don't talk to each other and have decided that twelve engineers in a room is the solution.

The meetings break the day into shards. Forty minutes between standup and the sync. Twenty-five minutes between the sync and architecture review. You cannot enter flow state in forty minutes. You can answer Slack. You can review a small PR. You can stare at the migration script and feel something resembling grief.

The senior dev's role in meetings is mostly translation. Translating product into engineering. Translating engineering into product. Translating what the principal engineer just said into something the new hire can act on. Translating the panic in the eyes of the project manager into a realistic timeline that includes the holiday weekend nobody has acknowledged yet.

Occasionally a meeting produces a decision. More often it produces a follow-up meeting. You schedule it on the calendar yourself, because if you don't, nobody will, and then the same conversation will happen again next Tuesday.

Unblocking the Juniors

A junior pings you at 10:15. Their tests are failing locally. You ask if they've pulled main. They have. You ask if they've rebuilt the Docker container. Long pause. They rebuild the Docker container. The tests pass. You return to your seat.

At 10:42, a different junior pings you. Their migration is failing in staging. You look at the migration. The migration is fine. The staging database is in a state nobody has documented since 2021. You spend twenty minutes archaeologying through Slack messages from a person who no longer works at the company, find a half-written runbook in a Notion page that hasn't been updated in eight months, and discover that the staging DB needs a specific seed step that lives in a script in a different repo. You document this for the third time, in a place the junior will not find next month when it happens again.

At 11:30, the first junior is back. Different problem. You context-switch. You explain the difference between git rebase and git merge for the fourth time this quarter. You do not sigh, because they can hear you sigh, and the goal is for them to keep asking instead of breaking production silently.

This is, depending on how you frame it, either the most valuable thing you do all day or the most invisible. Your output looks like nothing. The juniors' output looks like progress. That's the deal. If you wanted credit, you should have become a soloist.

The Slack Tabs Nobody Asked You to Watch

You are in #incidents, even though you're not on call. You are in #platform, because the platform team's changes can break your service and they will not warn you. You are in #releases, because someone has to know what shipped. You are in #frontend-questions, because two years ago you fixed a bug there and now you're considered an authority. You are in #random, against your better judgment.

You scan these channels in the negative space between everything else. You answer a question here. You correct a misunderstanding there. You drop a link to the runbook you wrote in 2022 that everyone forgets exists. You are, functionally, a search engine with opinions. Your value is not in the answers themselves — those are mostly in the docs — but in knowing which doc to point at and which doc is wrong.

Nobody notices when you do this well. Everyone notices when you stop.

Design Docs and the Long Game

Somewhere in the calendar — if you've protected it, which you probably haven't — there's a two-hour block labeled "deep work" or "design" or just an ominous "WORK." This is the block where you're supposed to do the thing they actually pay you for: think about the system.

You're meant to be writing the design doc for the next quarter's project. The one where you decide whether to extract the billing logic into its own service or keep it where it is and just suffer. You have opinions. You have data. You have three competing diagrams in a Figma file that you keep meaning to clean up. What you do not have, on most days, is the two uninterrupted hours.

When you do get them — usually on a Friday afternoon when everyone has checked out — you produce the artifact that will shape six months of engineering work. The design doc gets reviewed, argued over, revised, and shipped. Nobody remembers, three months later, that it took fourteen drafts. They remember that the system works, or doesn't.

This is the part of the job that compounds. Every other hour of your day is fungible. The design doc is not.

On-Call, Or: Why You Keep Your Laptop Closed Mid-Tap

Pager goes off at 2:14 a.m. It's a flapping alert on a service you don't own but inherited responsibility for during a reorg fourteen months ago. You SSH in, kick the thing, acknowledge the page, write a one-line incident note, and go back to bed. You will not sleep well. In the morning, you will write the postmortem nobody will read, and you will add an item to a backlog that already has 200 items.

On-call is the cost of seniority that nobody mentions in the offer letter. The juniors are on the rotation too, technically, but they escalate to you, so functionally you are always on call. You learn to keep your phone face-down at dinner. You learn to glance at it anyway.

Q&A

Q: When do you actually write code?

Friday afternoons, between 4 and 6. Saturday mornings, if the project is interesting enough and the family is asleep. The occasional Tuesday where every meeting cancels and the universe permits a small miracle.

Q: Do you miss being a junior?

You miss the focus. You don't miss the anxiety. The trade is mostly fair.

Q: How do you measure productivity if you're not shipping code?

You don't, really. You measure it by whether the team shipped. If the team shipped and nothing exploded and three juniors are slightly better engineers than they were last quarter, you had a good month. If the team shipped but you spent the whole month firefighting and the juniors learned nothing, you had a bad month, even if the metrics dashboard disagrees.

Q: Is it worth it?

Most days. The days it isn't, you reread the offer letter, look at the comp, and approve another PR you mostly read.

Closing

The job is not what the title says. The title says engineer. The job is part editor, part translator, part archaeologist, part janitor, part teacher, and occasionally — when the calendar gods are merciful — engineer. You learn to take the wins where they appear: a clean review, a junior who finally got it, a design doc that ended a six-week argument in a single paragraph. You close the laptop at 6:30. The migration script is still there. It'll keep until Monday.