The trap
I did a set of exercises this morning to raise my energy, then showered, because I've learned
I need to feel physically settled before my mind is any good to me. Only afterward, reading a
chapter about hunter-gatherer instincts colliding with modern life, did I have language for
why. The insight came after the action, not before it. That ordering turned out to matter
more than the insight itself.
Here's the trap I nearly walked into. I read a compelling argument, that a mismatch between
old wiring and new environments explains a lot of modern unease, and I started treating it as
settled. Not because the evidence demanded it, but because the writing was good. A well-made
argument and a demonstrated fact produce the same feeling of certainty in a reader. That
feeling is not evidence. It's craft.
The distinction that actually matters
A claim is something shown to be true, checked against reality, falsifiable and unfalsified.
An argument is something made to be believed, structured, sequenced, persuasive by design.
Good nonfiction is full of arguments dressed in the confidence of claims, and the better the
writing, the harder that becomes to notice. The specific idea I was reading, that suppressed
movement contributes to depression, is a real argument worth taking seriously. It is not a
settled account of what causes depression, which research treats as a tangle of contributing
factors, not a single mechanism. Losing that distinction wouldn't just cost me an accurate
view of one book. It's the kind of thing that quietly reshapes how you read your own career
decisions, your own dissatisfaction, your own choices, once a persuasive frame is sitting
unexamined in the back of your head.
There's a second version of the same trap, closer in: I'd summarized what I'd read, in my own
words, and then treated my own summary as if it were a faithful account of the source. It's
entirely possible I misread the chapter. My understanding of an idea and a verified account of
that idea are not the same thing, and conflating them means any misreading I make gets
laundered into something that looks like the author's authority instead of my own.
Where I'd already been doing this right
The clearest working example of separating claim from argument that I have access to isn't
philosophical at all. It's a settlement-engine system I built myself, with Claude Code, and
am now restudying deliberately, not to relearn it from scratch, but to make sure I actually
know it well enough to explain it, in passing or in detail, on demand. That gap, between
having built something and being able to explain it under pressure, is one I've caught in
myself before. This restudy is a direct test of it.
What I found worth studying closely is a documentation habit built into the project itself: a
decisions log that doesn't just record what was decided, it records why, one sentence per
decision, stated plainly enough to be checked. "Foreign key validation failures return 400,
not 404, because the bad ID is client input error, not a missing resource being fetched
directly." That's not a conclusion asserted with confidence. That's a reasoned claim, sitting
next to the reasoning that produced it, inviting disagreement rather than discouraging it.
Compare that to a decisions log that just says "we chose 400." Both read as authoritative if
you don't look closely. Only one of them actually lets you check the reasoning instead of
just trusting the confidence of the person who wrote it. That's the whole trick. Confidence is
cheap. Showing your work is not.
What this looks like day to day
In reading: hold two separate questions for anything persuasive. What is being claimed, and
what is being argued for. Notice which one produced your certainty. If it's the second, the
certainty is borrowed from the writing, not earned from the evidence.
In relationships and self-observation: distinguish what happened from what you concluded it
meant. A single explanation that fits doesn't mean it's the only one, or the right one, it
means it's plausible enough to feel finished. Plausible and finished are not the same
condition.
In code, and in any documentation that describes a system: treat a decisions log entry, a
comment, or a design doc the way you'd treat a persuasive book, with the same two questions.
Does this line state a checkable reason, or does it just assert a conclusion with confidence?
A codebase full of confident assertions with no reasoning attached is tunnel vision waiting to
happen, for whoever reads it next, including the person who wrote it, six months later,
having forgotten why. That's precisely the risk I'm restudying my own system to guard
against, having built it doesn't guarantee I could still explain it cold.
The actual discipline isn't suspicion of everything. It's narrower than that: know which of
your beliefs are standing on demonstrated ground and which are standing on good writing, good
confidence, or your own possibly-mistaken summary of something else. Most of the time you can
hold both kinds of belief at once, loosely, without needing to resolve which is which
immediately. The problem only starts when you stop checking.
No tidy ending
I don't have a tidy ending for this one, and I'm treating that as correct rather than
unfinished. The whole point was to stop mistaking a well-argued position for a demonstrated
one. Reaching a neat conclusion here would be exactly the thing I just spent this piece
arguing against doing.
What I took from it
- Certainty from good writing feels the same as certainty from evidence. Check which one I'm standing on.
- My own summary of a source is not the source. Mark it as mine.
- A decision is only checkable when its reason is written next to it, in code and in life.
- Not every belief needs resolving now. The problem starts when I stop checking.
Originally published on my site.
