System design

A while ago I tried to write down what separates a top 1% software engineer from a junior, in skills you could actually name. This note is the living version of that list.

The skills, named

• Domain-driven design — the code's vocabulary matches the business's vocabulary, so a conversation with a stakeholder is also a code review.
• Recognizing code smells — not memorizing the catalog, but feeling the friction early, when renaming is still cheap.
• Design patterns — knowing them well enough to know when not to use them. A pattern applied before the pain it solves is just ceremony.
• System design — drawing the boxes is easy; the skill is knowing what each layer demands from the layer below it, and what it promises to the layer above.
• End-to-end ownership — from writing code to watching it run in production. The gap between "works on my machine" and "works" is where seniority lives.

What each layer demands

The question I ask of every architecture diagram: what does L1 request from L2, and what does L2 promise back? If the diagram can't answer that, it's a drawing, not a design.

L1: UI          → demands: fresh state, fast    → promises: user intent
L2: Application → demands: consistent domain    → promises: orchestration
L3: Domain      → demands: durable storage      → promises: invariants hold
L4: Storage     → demands: hardware that works  → promises: durability

Every interface is a contract. Most bugs are one layer assuming a promise the other layer never made.