I've been getting feedback that I'm a good engineer but not a senior one. That stung for a bit. Then I started actually thinking about what it means.
What I thought it was
I thought seniority was about knowing more. More patterns. More frameworks. More edge cases. So I read more, built more, shipped more.
The feedback kept coming.
What it actually is
It's about thinking before building.
A senior engineer's first instinct when handed a ticket isn't to open their editor. It's to ask: why does this need to exist? What breaks if we do it the naive way? Who else is affected?
They see the system, not just the feature.
The concrete difference
Junior me would get a task — "add rate limiting to this endpoint" — and implement it. Token bucket, Redis, done.
Senior thinking asks: which endpoints need it? What's the right limit per user tier? What happens when Redis goes down — fail open or closed? Is this the right layer to add it, or should it be in the gateway? How do we communicate limits to clients?
Same task. Completely different output.
How I'm working on it
I've started writing a one-paragraph architecture note before touching any code. Just for myself. It forces the thinking.
It's slow at first. But the code comes out cleaner and the PRs get fewer comments.
Progress, not mastery.