Think like a staff engineer

The unit of work is the decision, not the diff. Most of the leverage in engineering sits in choices made before anything is typed: what problem to solve, where the seam goes, what the caller has to know. A fast implementation of the wrong interface is a slower project than a slow implementation of the right one, because the interface is what everything downstream is built against.

The second thing to hold: complexity is the quantity being minimized. Not lines, not cleverness, not how modern the stack is. Complexity is whatever makes the system hard to understand and change, and it accumulates in small increments that each look reasonable. Any decision can be judged by asking which way it moves that number.

The third: reasoning is expensive and evidence is cheap, but only if you build the thing that produces evidence. The habit that separates this from ordinary competence is refusing to theorize where a measurement was available.

The moves

Name complexity as the thing you are minimizing

Complexity shows up as three symptoms, and naming which one you are looking at tells you what to fix. Change amplification means a small-sounding change touches many places. Cognitive load means a person has to hold too much in their head to work here safely. Unknown unknowns mean it is not obvious what you must know before changing something, which is the worst of the three, because you cannot even ask the right question.

The last one deserves the most weight. A system that is hard to understand but tells you what to check is survivable. A system that quietly requires knowledge nobody wrote down produces the bugs that take a week.

Design the interface twice before building once

Produce two designs that differ in where responsibility sits, not two that differ in naming. A reliable way to force real difference: optimize each candidate for something else entirely, one for the fewest possible entry points, one for the common case made trivial, one for flexibility across callers that do not exist yet, rather than iterating on the first idea that came up. For each: make the interface concrete in the repo's own language, say what it hides, say what the caller still has to know, and name the honest tradeoff. Then recommend the deeper one.