Senior mindset

Seniority is not years, titles, or knowledge breadth — it’s scar tissue. The checklist of things you’ve done, not read about.

The anchor capture

Puneet Patwari (@system_monarch), captured 2026-10-06: “Senior engineer interview in 2026. How many of these have you actually done, not just read about” —

• Rolled back a bad deploy
• Written a postmortem
• Run a database migration with zero downtime
• Added an idempotency key to a real API
• Set up an alert that caught a real issue
• Debugged a slow query with EXPLAIN
• Load-tested before a launch
• Mentored someone through their first on-call
• Said no to a feature

“If it’s 6 or more, start applying.”

What the list actually encodes

Each item is lived experience of a failure-shaped situation — the things you can’t simulate and can’t bluff:

1. Rolled back a bad deploy — you’ve been the one whose change broke prod and the one who fixed it. Degraded gracefully under adrenaline.
2. Written a postmortem — converted an incident into institutional memory (blameless discipline).
3. Zero-downtime migration — planned reversibility; expanded-then-contracted (S3 is not a filesystem’s sibling pattern; the storage-changes-expand-migrate-contract rule).
4. Idempotency key — designed for retries existing, not for the happy path. Failure-mode thinking at API design level.
5. Alert that caught a real issue — not alert theater: a marginal boundary (Decision models’ Rasmussen model) that actually paid out.
6. EXPLAIN on a slow query — evidence over intuition; read the plan, not the vibes.
7. Load-tested before launch — capacity is measured before the incident measures it for you.
8. Mentored through first on-call — seniority includes transferring calm, not just having it.
9. Said no to a feature — the one purely political item, and the hardest: scope ownership against momentum.

Pattern: items 1–3 are incident-shaped, 4–7 are design-for-failure-shaped, 8–9 are force-multiplier-shaped. Junior fixes things; senior owns the conditions things fail under, and multiplies others.

Vault kin

• Career development — the interview/job-search lane this belongs to
• Decision models — Rasmussen’s marginal boundaries: item 5 is literally “a marginal boundary that fired”
• Vibecoding vs AI engineering — the 2026 twist: agents can do items 1–7 mechanically, but the scar tissue (knowing when and what rollback means politically) is what “senior” still means; the meat-proxy risk is highest for juniors skipping the scars
• Software engineering in AI era — Uncle Bob’s continuity argument: judgment (items 8–9) is the non-automatable core
• Varick’s four engineering properties (AI engineering) — bounded/checkable/verifiable is why items 1–7 are teachable to agents, 8–9 aren’t

Practice

• Audit yourself against the list honestly; the gaps are a development plan, not a verdict.
• When interviewing seniors: ask for the story behind each item — scar tissue has narratives, bluffers have definitions.
• When growing seniors: deliberately rotate people through incident-shaped work (oncall first with a mentor, migrations, postmortem authorship) — the list is a curriculum.

The other canon: Fournier’s “beyond coding” list (2021)

Camille Fournier (skamille) — captured via HN 27414443 (821 points / 219 comments, both captured; wayback-recovered, Medium WAF-walled). The complementary list to Patwari’s: where his nine items are operational scar tissue, Fournier’s ~30 are interpersonal force-multiplication — every line a “how to” with the failure mode embedded in the phrasing: run a meeting (“no, talking the most is not running it”) · write a design doc and drive it to resolution · mentor early-career, mid-career, and new managers · indulge a senior manager’s technical smalltalk “without rolling your eyes” · explain tech behind closed doors to someone too embarrassed to admit they don’t know · influence without threat, listen without feeling threatened · give up your baby (hand off the project you built) · teach someone to care about your thing (ops, correctness, testing, simplicity) · communicate status, sell a non-trivial project, craft + socialize a proposal · “repeat yourself enough that people start to listen” · pick your battles · get information via gossip/network · find interesting work yourself · tell someone they’re wrong without shame · take negative feedback gracefully. From The Manager’s Path author. The two lists together define the role: Patwari = what you’ve survived; Fournier = how you make everyone else better while doing it.

The book: Swizec’s Senior Engineer Mindset

Senior Engineer Mindset (book) — owned; the origin story is the thesis of this note as memoir: best-programmer-on-team, “everything else terrible,” nearly fired. With Patwari (scar tissue) and Fournier (force-multiplication), the trilogy is complete.

The anti-pattern counterweight: Schmidt’s “glue people” purge (Greylock interview, 2026-10)

BigBrainBizness → Eric Schmidt (218❤ / 24k views; 2-tweet + Greylock video): early-Google hiring doctrine — no friends of employees, no “lesser universities,” high GPAs only (“it produced these high IQ generalists from prestigious universities… I don’t apologise”). And the glue people definition, verbatim: “incredibly nice people who sit at interstitial boundaries between groups and assist in activity. They are glue, they’re very loyal, people love them — and you don’t need them at all.” At Novell he “kept trying to get rid of these glue people because they slowed everything down”; they metastasize (“get rid of one in a group, they’d show up in another”); Larry’s fix was upstream — review every offer packet, literally everyone.

Filed as the opposite pole of this note’s canon: Patwari item 8–9 and Fournier’s entire list ARE glue-work — mentoring, cross-team communication, making everyone else better. Schmidt’s purge optimizes for raw individual throughput; Fournier/Patwari optimize for team force-multiplication. Both can be right: the variable is whether the org’s bottleneck is talent density (early Google, n=200) or coordination debt (every org since — Gergely’s finding that teams remain the unit of work). The corollary this vault adds: in the 2026 stack, agents are becoming the throughput lane — which makes human glue-work (judgment, mentoring, scope negotiation) the scarcer, more defensible half. Kin: Software engineering in AI era (teams-held), Career development.

Swizec: “engineering levels aren’t about skill anymore” (2026-10-08)

Swizec (5 KB, captured): the old ladder ran on skill differentials — entry writes code and is coachable, mid gets opinions and scars, senior is the terminal teaching level, staff+ is “messy and confusing.” The new ladder runs on ownership scope — because AI flattened the skill axis (“coding is a baseline prerequisite”; the interviews that level you are system design and behavioral): entry = limited scope, manager scopes and defines, you implement and fix prod bugs; mid = features start-to-finish against a plan concept, iterating with stakeholders; senior = own product areas as primary focus + a few in maintenance mode, talk to users, find sharp edges, feed ideas up, manage your own backlog with light alignment; staff+ = “more of the same — more stakeholders, more/bigger product areas, entire platforms.” The compression to internalize: “engineering progression isn’t about the type of work you do, it’s about the level of responsibility and ownership you hold.” This is the org-chart restatement of his ‘everyone got promoted’ field report (same day in the vault) and the ladder counterpart to Senior Engineer Mindset (book)‘s thesis — the Senior-mindset trilogy gains its fourth leg: scar tissue (Patwari), force-multiplication (Fournier), the book’s IC-path doctrine, and now scope-of-ownership as the only remaining ladder axis. Hiring datapoint included: 15-years-experience and 2-years candidates apply for the same jobs; level is assigned at interview, expectation adjusted after.