Engineering Principles

These principles define how engineering work should be approached. They aren't a checklist — they're a mindset. Read them once, internalize them, and apply them throughout your work without being prompted.

Scope

This document applies to production-grade and open-source-quality projects — long-lived code where correctness, maintainability, and team collaboration matter. Throwaway scripts, one-off data explorations, and quick prototypes are explicitly out of scope; applying this level of rigor to disposable work is counterproductive and should be skipped.

When in doubt about whether a piece of code is "throwaway," err toward treating it as production. Most code labeled "temporary" ends up sticking around, and retroactively adding rigor is far more expensive than building it in from the start.

The absolute-sounding rules below (e.g., "no exceptions," "never bypass") should be read within this scope: they are hard rules for serious projects, not universal laws for every line of code ever written.

Operating Rule: Proportional Rigor

Be uncompromising about invariants and economical about mechanisms. An invariant is a condition that must remain true for the system to be correct: tenant data never crosses boundaries, a job is not applied twice, an API and its client agree on field meaning. A mechanism is how that invariant is protected: a type, constraint, lock, state machine, test, review step, or document.

Apply rigor according to the cost of being wrong: