Principles

01. Clarity core

Clarity is the master principle. Clarity in thinking — understanding something well enough to explain it simply. Clarity in writing — saying what you mean without extra ceremony. Clarity in code — naming, structure, and interfaces that communicate intent so completely that comments become redundant.

"Clever" is the enemy of clarity. So is premature abstraction, overloaded vocabulary, and the kind of prose that mistakes density for depth. When I notice that something I wrote is hard to understand, that's a signal that I don't fully understand it yet — not that the reader needs to try harder.

This applies to the site itself. One column. One CSS file. One accent color. The design is clear because it has almost nothing in it. What remains is the writing.

02. Durability candidate

Prefer things that last over things that are clever. In software: plain files over fancy frameworks, frozen URLs over convenient redirects, boring technology over the newest shiny thing. In writing: ideas that will still be true in a decade over observations about last week's news cycle.

Durability is not conservatism. It's the discipline of asking "what is the useful life of this decision?" before making it, and choosing accordingly. A decision with a 10-year useful life is worth more than ten decisions with a 1-year life — even if the short-lived ones are individually more interesting.

03. Simplicity candidate

Fewer moving parts is a feature, not a tradeoff. Complexity is usually accumulated accidentally — one reasonable decision at a time — and rarely noticed until you're staring at a failing build at 11pm and can't remember why you added the thing that's now on fire.

The cost of complexity is invisible while you're adding it. The cost becomes visible when you're maintaining it, debugging it, or trying to hand it to someone else. I try to evaluate decisions as their future maintainer, not their current builder.

The practical test: if you removed it and nothing broke for a month, you didn't need it. If removing it would cause a cascade, you should understand why before you leave it in place.

04. Honesty candidate

Write about what actually happened, not what you wish had happened. This sounds obvious until you sit down to write about a decision that turned out badly, and feel the pull to frame it as a learning experience you'd planned all along.

The same applies to code. A comment that says "this is a hack" is better than one that implies the hack is intentional design. A commit message that says "revert — this broke production" is more useful than one that says "adjust timing." Honesty in small things keeps you calibrated for the big ones.

05. Compounding candidate

Prefer investments whose value grows over time. Writing compounds: each post makes the next one easier and creates a record that gets more useful the longer it exists. Systems that log their own decisions compound. Skills that cross domains compound. Time spent understanding fundamentals compounds.

The opposite also holds. Technical debt doesn't compound in your favor. Dependencies you don't understand don't compound. Moving fast without writing anything down doesn't compound. I try to notice which category a given investment falls into before I make it.