There's a belief that never quite dies in software teams: the best senior engineer is the one with the most commits. The one who closes the most tickets, ships the most features, and grinds through the most pull requests. I used to believe it too. I was wrong — and I think this belief is quietly damaging a lot of teams.
Senior engineers should code less. Not because coding doesn't matter, but because at a certain point, your highest-leverage contribution stops being the code you write and starts being the code your team writes better because of you.
What "Senior" Actually Means
The title is misleading. "Senior" sounds like it just means "a lot of experience doing the same thing." In reality, seniority in engineering should mark a transition — from individual contributor to force multiplier. A junior engineer who writes great code improves one part of the product. A senior engineer who raises the quality bar for five other developers improves the entire product, permanently.
But that kind of impact doesn't come from staying in your editor all day. It comes from:
- Reviewing code in a way that teaches, not just approves or rejects
- Writing architecture decision records that prevent future debates
- Asking the right questions in planning so the team doesn't build the wrong thing
- Unblocking people fast instead of protecting your own deep-work blocks
- Spotting the systemic problem behind three separate bug reports
None of that shows up cleanly on a commit graph. And that's exactly the problem with how most teams measure engineering contribution.
The Case for Staying Heads-Down (Steel-Manning It)
I'll be fair: the other side has real arguments.
First, there's the credibility point. Senior engineers who stop coding lose their technical intuition fast. If you're reviewing an architectural decision or estimating complexity without recent hands-on context, you're guessing — and experienced guessing isn't the same as knowing. Teams can tell when leadership has gone soft on technical depth, and it erodes trust.
Second, there are genuinely situations where a senior engineer's direct coding output is irreplaceable. Critical performance bottlenecks, security-sensitive systems, or prototype work where the goal is to validate an idea fast — these sometimes need the most experienced hands on the keyboard.
Third, coding is often where senior engineers find meaning and satisfaction. Pushing someone out of the work they love in the name of "leadership" can be a fast path to burnout and attrition. Not every great senior engineer wants to become a manager, and that should be respected.
These are real concerns. I'm not dismissing them.
But Here's What We Get Wrong
The problem isn't that senior engineers code. The problem is that many senior engineers code at the expense of everything else — and nobody holds them accountable for it because commits are visible and mentorship is not.
I've seen this pattern repeatedly: a senior engineer is proud of their output, ships constantly, and is genuinely technically excellent. But the two junior developers sitting near them are stuck, confused, and quietly losing confidence — because that senior engineer is too busy shipping to answer questions. The team's velocity looks fine on paper. The actual growth of the team is stalled.
Meanwhile, the senior engineer who codes a bit less but conducts thoughtful code reviews, helps a mid-level engineer rearchitect a messy service correctly, and pushes back on scope creep in sprint planning? That person is often perceived as "doing less" in cultures that fetishize output metrics.
That perception is the bug, not the behavior.
The Leverage Shift Is Real
Think about it in plain terms. If a senior engineer codes all day and produces, say, twice the output of a mid-level developer — that's a 2x contribution. If that same engineer spends part of their week helping three mid-level developers get 30% better at their jobs, the long-term multiplier is far beyond 2x. And it compounds. Better developers make better decisions, write better code, and eventually mentor others themselves.
The engineers I've learned the most from in my career were not the ones with the most impressive individual outputs. They were the ones who made time for me, who asked hard questions about my approach, who flagged things I would have missed for years otherwise. That's not soft skill fluff — that is engineering leverage.
Where I Land
Senior engineers should stay technical. They should absolutely keep coding — enough to maintain sharp intuition, enough to stay credible, enough to do the work only they can do. But coding should not be their primary daily activity by default.
If you're a senior engineer and your calendar is mostly uninterrupted coding blocks with occasional code reviews squeezed in — I'd push you to ask honestly: is your team actually growing because of you? Or are you just a very experienced individual contributor who happens to sit near other developers?
The best senior engineers I know are in the code enough to stay sharp, and out of it enough to make everyone around them sharper. That balance is hard to find, harder to measure, and more valuable than any commit streak.
