Engineering

"Premature optimization is the root of all evil" is the most-quoted line in programming. It's true. But it's been twisted into an excuse to ignore performance entirely — and that's its own kind of evil.

"Build what customers ask for" is good advice that becomes a trap. Customers describe their problems in the language of existing solutions. The best features are often the ones nobody requested — because nobody knew to.

AI can write code faster than you can think. That's either the biggest productivity unlock in a generation or a slow erosion of real engineering skill. Which one depends entirely on how you use it.

Most engineers think of tests as bug-catchers. That framing leads to bad tests. The real purpose of a test suite is confidence — the freedom to change code without fear. Reframe it and you write better tests.

A great API feels obvious — you guess how it works and you're right. That feeling isn't an accident; it's the product of dozens of small design choices most teams never think about.

New frameworks drop constantly, each promising to change everything. Chasing them is how teams end up rewriting instead of shipping. Here's how to choose a stack you'll still be happy with later.

The AI conversation is obsessed with the biggest, most capable models. But for a huge range of real tasks, a smaller, faster, cheaper model is the better choice. Capability you don't need is just cost.

Code review is either a team's best learning tool or a source of dread, ego battles, and bottlenecks. The difference isn't the tooling — it's the culture. Here's how to get it right.

Most technical docs are written to be complete, not to be used. There's a difference, and it's why developers skip your beautiful docs and go straight to the source code.

There's an old joke that the two hardest problems in computer science are cache invalidation and naming things. The joke is real. Good names are documentation that never goes stale — and bad ones are bugs waiting to happen.