What Senior Actually Means
Seniority isn't a measure of how much you know. It's a measure of how well you know what you don't know — and how systematically you close those gaps before they become incidents.
The title “senior engineer” is one of the most inconsistently applied labels in our industry. I have seen it awarded to people who could reverse a binary search in under thirty seconds and withheld from people who could architect a distributed system from first principles. The inconsistency is not accidental. We are measuring the wrong thing. We are measuring knowledge density — how much someone knows — when we should be measuring knowledge calibration — how accurately someone can assess what they don’t know.
Dunning-Kruger is misused more often than it is cited, but the underlying observation is real and relevant: novice practitioners consistently overestimate their competence, and experts consistently underestimate theirs. Not because experts are insecure, but because experts have a more accurate model of the territory. They know how much there is to know. The junior engineer who thinks they understand concurrency is often more dangerous than the junior engineer who knows they don’t, because the first will write production code and the second will ask questions. Senior engineers have learned to be afraid of the things they don’t understand, and that fear expresses itself as system — as patterns for managing uncertainty, as principles that don’t require full understanding to apply correctly, as the habit of designing for the case you haven’t anticipated.
This is why seniority so often shows up in how someone responds to a problem they’ve never seen before, rather than in how they solve a problem they have seen before. Anyone can implement a feature from a spec when the spec is good. The senior engineer is identifiable in the room where the spec is ambiguous, where the requirements conflict, where the constraint that matters isn’t written down because no one realised it was a constraint. They ask a different set of questions: not “what do I need to do?” but “what would have to be true for this to work, and how would I know if it stopped being true?” They are not more confident. They are more careful.
The practical implication is that seniority is not a state you achieve. It is a practice you maintain. The senior engineer who stops learning, who stops updating their model of the system, who stops being surprised by their own blind spots — that engineer is not senior by virtue of tenure. They are senior by habit: the habit of noticing what they don’t know, and acting on that noticing before it becomes an incident. The most senior people I have worked with have a specific quality in common, which is that they are comfortable being the least experienced person in the room. Not performing humility — genuine comfort with it. Because they know that the alternative is pretending, and pretending in a system context means introducing risk that you cannot see. The senior engineer would rather learn than perform. It is a small distinction and it changes everything.