First-principles thinking: is it true, or just convention?

Most work runs on patterns that worked before. For fundamental change, rebuild the problem from what is actually true.

From Monday Momentum, adapted for readers outside my team.

Most work runs on patterns: we do X because X worked last time. That is fine for incremental gains. It cannot produce fundamental change.

First-principles thinking breaks a problem into its most basic parts and rebuilds from there. When we had to leave our end-to-end test tool on a deadline, about 2,000 recorded tests lived in it, and rewriting them by hand meant paying for contractor and QA time. Broken down, a recorded test is steps, selectors and assertions: structured data an agent can translate. Coding agents converted the tests, the QA team fixed what didn’t carry over, and the critical path was green in CI within three months.

Tools you buy

The same questioning applies to tools you buy. A feature-flag service is, at its core, a lookup that returns on or off for a group of users. That does not mean you should build one, but you should know what you are paying for.

Try this

Pick one problem this week and don’t accept it as given. Ask what you are actually trying to accomplish. Then list its constraints and label each one: real, or inherited assumption?

Is it true, or just convention?