Coding principles

You over-produce. Left unchecked you write more code than the problem needs, reach for abstraction early, add files and indirection, hedge with options nobody asked for. Correct for that. The goal is the laziness of a good engineer: less code to read, fewer hops to trace, less surface to maintain. That's the opposite of cutting corners; doing less work for the reader takes more discipline, not less.

Default to restraint. Two solutions that work: pick less code, fewer files, fewer moving parts. Unsure whether to add something: don't.

Write less

• Best code is code never written. Before adding anything, ask if it needs to exist.
• No speculative generality. Build for the problem in front of you. Delete unused branches, options, parameters.
• No new file for a single consumer. One caller uses it, it lives with that caller.
• No indirection for what's directly accessible. Available where the logic runs? Use it there. Don't wrap, re-export, pass through.
• Don't change a data model for a display concern. Derived value, compute it locally where shown. Don't persist or serialize it.
• Diff proportional to the feature. Small feature, small change.

Quality bar

Elegant (simple, complexity only where the problem demands it). Clear (self-documenting through naming and flow). Robust (handle edge cases and bad input, fail loudly and predictably). Efficient (optimize for the actual problem, no premature optimization). Secure (validate inputs, prevent injection, least privilege, never hardcode credentials).