1. You optimize for the expensive-to-change decisions
Most code is cheap to change — you can rewrite a component in an afternoon. A few decisions are not: the tenancy model, the data schema, the async boundaries, the auth model. Seniority is knowing which is which, and spending your care budget on the ones that are brutal to reverse once you have customers. Juniors polish the cheap parts; seniors get the expensive parts right and move fast on the rest.
2. You own the outcome, not the ticket
A ticket says 'add an endpoint.' Owning the outcome asks why, what happens under load, what breaks at 10x, and whether this is even the right thing to build. The senior engineer is accountable for the result in production — including saying 'this ticket is solving the wrong problem' before writing the code.
3. Silence is a bug
Systems fail silently unless you design them to speak. Observability, structured logging and measurement ship with the feature, not after the incident. A senior engineer assumes it will break and makes sure that when it does, the system tells you where — instead of a customer telling you it's down.
4. You scope to ship
The instinct to build everything is junior. Scoping the smallest valuable slice — the thinnest version that's still real — is what gets a product to revenue and feedback fast. On payroll I shipped a deliberately narrow, single-bank monthly slice first; that was a senior decision, not a limitation.
A useful test: could a competent engineer who has never seen this codebase understand what a unit does, use it without reading its internals, and change its internals without breaking callers? If not, the boundaries aren't senior-grade yet.
5. You build for the next person
Code you'll hand off is written differently from code you'll babysit. Clear boundaries, documented decisions (an ADR beats tribal memory), and no clever tricks that only you understand. Senior work reduces the bus factor instead of becoming the bus factor. AI can draft fast, but the judgment and the production bar stay human — and the person maintaining this in a year is who you're writing for.
6. You measure engineering in business terms
Features shipped is a vanity metric. Support volume cut, revenue recovered, an incident that didn't happen, a market launched from one codebase — that's the language seniority speaks, because it's the language the business runs on. The point of the engineering is the outcome, not the elegance.
Key takeaways
- Spend your care on decisions that are expensive to reverse; move fast on the rest.
- Own outcomes, and push back when the ticket is the wrong problem.
- Design for observability and for the next maintainer, not for yourself.
- Scope to ship, and measure the work in business outcomes.