Principles

Default to composing behaviors from small, focused pieces. Use inheritance only for genuine 'is-a' relationships, and...

Coupling has a rankable strength; a good refactor moves it to a weaker form, and weaker still as distance grows.

A system's architecture mirrors the communication structure of the teams or agents that build it — so shape those boundaries to match the design you want.

Trading rigor for speed is legitimate only when the choice is deliberate, recorded, and has a payback trigger.

A component should receive its dependencies from the outside, not construct them internally:

Every line of code is a maintenance liability. Build disposable software, not reusable software:

Every piece of knowledge should have a single, authoritative representation. DRY is a rule about knowledge, not about code shape.

Represent expected, recoverable failures as values so failure paths show up in signatures and must be handled.

Hidden behavior, magic, and implicit coupling create bugs that take days to find:

Invalid state should be detected and surfaced immediately at the point of origin, not propagated silently:

When no native solution exists, research battle-tested open-source libraries and present options to the user before b...

User actions and system operations should be safe to repeat without duplicate side effects:

Mutable shared state is the root cause of most concurrency bugs. Default to immutable values; introduce mutability on...

Encode invariants in types and parse untrusted input once into a value that carries proof of its own validity.

Separate correctness, design quality, and performance into sequential phases:

Well-defined boundaries between subsystems let each side evolve independently. Define ports (interfaces) that describ...

Every principle above is a strategy for making future change cheaper and safer. When evaluating any technical decisio...

Always use the platform's built-in frameworks before custom implementations. Swift Concurrency over raw threads. Room...

APIs, UI, and system behavior should match what users and callers expect. If a name suggests one behavior, it must de...

A module should have one reason to change. If describing what a module does requires 'and,' consider splitting. This ...

Simple and easy are not synonyms. Simple means no interleaving of concerns. Easy means familiar or convenient. Optimi...

If a decision is cheap to reverse, make it fast. If it is expensive to reverse, invest in understanding first:

A module should be answerable to one and only one actor. Reason-to-change is a stakeholder, not a concern.

Build the thinnest end-to-end slice through every boundary before breadth — the disciplined answer to scaffolding vs YAGNI.

Applications should expose their capabilities through automation interfaces, not just interactive UI.

The speed of your feedback loop is the speed of your learning:

Build for today's known requirements. Speculative generality adds code that must be maintained but delivers no curren...