Source Priority: Where Good Decisions Come From

Every decision about how to build something rests on something you trust — a doc, an example, a half-remembered habit, a stranger's confident answer. The mistake is treating those as interchangeable. They aren't. A claim from the official specification and a claim from an unattributed forum post can flatly contradict each other, and if you can't rank them, you'll sometimes build on the weaker one without noticing. The work inherits the reliability of its sources, so the order you trust in isn't pedantry — it's quality control at the root.

Here's the order I actually use. Primary sources first — the official documentation, the specification, the real source code — closest to the truth because they are the thing. Then battle-tested practice: widely-used libraries and patterns that survived real production for years; not the truth itself, but reliability earned the hard way. Then secondary commentary — blogs, tutorials, forum answers — useful for orientation, one interpretation removed and often out of date. And last, memory and guesswork, trusted only until you can confirm it against something higher.

One fact, one home

The ladder ranks the sources outside you. Inside your own work, the same instinct has a sharper form: every fact should have exactly one home, and everything else should be derived from it, never copied beside it. The moment the same truth lives in two places — a constant pasted into three files, a number kept in both the code and the docs — they are guaranteed to drift, and then you have two sources and no way to rank them. A single source of truth is just source priority applied to your own house: decide where a fact lives, and make every other place point at it rather than repeat it.

Where it goes wrong

The classic error is trusting the most confident source instead of the most authoritative one — a blog written with total certainty feels safer than dry documentation that hedges, but the certain stranger is often simply wrong with conviction. The fix is to rank by where a claim sits on the ladder, not by how sure it sounds. The subtler failure is trusting stale primary sources: docs go out of date, so the top rung is the current primary source, and checking the version is part of the climb. Match the source to the stakes — ten minutes in the spec for anything load-bearing, a quick answer for the trivial and reversible.

Put it to work

Next time you're about to build on something you “know,” pause and name the source. Which rung is it on — the spec, a proven library, a blog you read once, or just memory? If it's load-bearing and the source is low on the ladder, spend the ten minutes to climb. That small habit, repeated, is the difference between work that's quietly right and work that's confidently wrong.

From my own practice — prefer primary documentation and source over secondary commentary, keep one source of truth, and confirm before you trust.