Engineering principles

Pick the well-worn tool unless there's a real reason not to. Novelty is a tax on every future contributor — including your future self. Reserve excitement for the actual problem.

Code is read ten times more than it's written. A one-line bit of magic is a future bug — write the obvious version, name the variable, leave the type, move on.

Big batches hide big bugs. A daily-shipped change is a daily-tested change. Build the pipeline so a one-line fix can be in production before lunch.

Tests describe how the code is supposed to behave to anyone who reads them. Aim for tests that read like specifications, not assertions about implementation details.

Every dead branch, every unused helper, every wrapper that wraps a wrapper — gone. The healthiest pull requests in my history are net-negative on line count.

Every architecture decision shapes how the team works. Choose abstractions that make onboarding fast, ownership clear, and Friday afternoons quiet.

If you can't see it running, you don't actually own it. Logs, metrics, traces — wired in from day one, not bolted on after the first incident.

Stack Overflow is a starting point, not a destination. The truth lives in the library's source — and reading it makes you faster at every subsequent problem.

The engineers I admire most can't stop poking at things. Make space — protected, daily — to learn something the project doesn't strictly need.

Pentesting a system you didn't build teaches you more about your own code than any code review will. Adopt the attacker's mindset on Saturdays so the engineer's mindset is sharper on Monday.