Skip to content
Hussh
Connect MCP

The Engineering Bar

How 🤫 writes code: the Jeff Dean and Andrej Karpathy standard, and the production failures that taught us each rule.

Concept

TL;DR: Measure the real constraint before optimizing, keep modules small enough to lift out, treat cold start and blast radius as first-class, and never mistake a green status for evidence.

Status as of 2026-07-28: see body.

Two role models, deliberately in tension

Jeff Dean — measure the real constraint, then make the layout follow it. Simplicity at scale. After an incident, the interesting artifact is the failure geometry, not the fix.

Andrej Karpathy — small, modular, self-contained code someone could lift out without importing your whole world. Teach clearly. First principles over cleverness.

Dean pushes toward systems that hold together. Karpathy pushes toward pieces that come apart cleanly. Good code does both, and the tension between them is the point rather than a problem to resolve.

Measure before you decide

Do not optimize, cache, shard, or restructure on intuition. Get the number first. Our per-neighbourhood lazy loading exists because we measured a real memory ceiling, not because sharding sounded scalable.

Ask what the query shape actually is, and let the physical layout follow it. Proximity queries are geographically bounded, so a geographic partition is a free lazy-loading boundary. When the layout matches the query, an accuracy decision and a resource decision turn out to be the same decision.

Blast radius is a design property

Treat the module graph as a blast-radius diagram. Nothing generic may depend on something heavy.

We took an entire site down once because a marketing page transitively imported a directory index that was built at module load. The index outgrew the memory available at process start, and because construction happened during startup, every route went dark rather than just the one that used it.

Code like bacteria

Before adding code, ask whether the piece could be lifted out and still be useful. A function that needs five internal imports to be understood is too coupled. Build a coordinated backbone only where complexity genuinely demands it.

When a piece fails this bar, say so. A long route handler that merges several data sources inline may be correct and well tested, but it is not something anyone would copy. Name that as debt rather than letting it pass as finished.

Cold start is a first-class test case

A system that works warm and dies cold is a system that has not been tested. Peak memory during construction, not steady-state size, is what meets the ceiling. Health checks register after startup and therefore cannot observe a process that dies during it. Tests run warm, in a long-lived process, with a developer's memory — they are structurally incapable of catching this class of failure.

A status is not evidence. A response is evidence.

Two failures have shipped past a green check here, and both shaped how we verify:

  1. A deployment reported success while traffic stayed on an older revision.
  2. A catch-all route answered 200 for pages that did not exist, which made every check against it meaningless.

So verification must assert on content markers — a string that cannot appear unless the page rendered its own content — run a negative control that must fail, and enforce a floor such as an expected route count to catch a stale revision. If the negative control passes when it should fail, every other result in that run is worthless.

Honesty in reporting

State plainly what was verified and what was not. If there is no latency benchmark, say so rather than presenting a qualitative improvement as if it were measured. Never claim a certification, partnership, or endorsement we do not hold; "in pursuit" is a complete sentence. Where a success response means recorded rather than done, both the response and the documentation must say so.

Publish the failure alongside the fix. A team that only reports its good days eventually gets believed on none of them.

Guardrails ship with features

The interesting work is the feature. The work that saves you is the check that runs before the feature reaches a person. Nobody writes a case study about a boot-check. Write it anyway.

The two standing tests

Before calling anything done: would Jobs ship it — clean, simple, the detail obsessed over, nothing extra? Would Munger call it wise — honest, rational, a genuinely good idea rather than a clever one? If it fails either, it is not done.

Sources