This Is Not My Hat

The discipline most people skip when they should care about it most

You write a blog post. You make a claim. Someone comments that the claim is wrong. You reply with more confident claims. This is a real thing that happens constantly in technical writing, and it wastes everyone's time. There is a small children's picture book by Jon Klassen published in 2013 called This Is Not My Hat. A small fish steals a hat from a big fish, and when questioned, insists repeatedly that the hat is not his. The illustrations tell a different story. The book is funny. It is also a remarkably accurate model for how people behave when they have taken something they do not fully understand and are now trying to pass it off as their own.

This Is Not My Hat as a working principle

I started using this concept as a personal filter a few years ago, more out of frustration than design. I had been burned repeatedly by writing things with too much certainty, and the corrections stung. The principle is simple: before you publish anything, check whether the claim is actually yours to make. If you are repeating something you read without verifying it, that is not your hat. If you are stating a conclusion without the evidence to back it, that is not your hat. If you are confident about a mechanism because it seems logical but you have never tested it, that is definitely not your hat. The habit took me about six months to build properly. I kept catching myself mid-sentence on forums and Slack channels, realizing I had stated an opinion as a fact. The worst one I remember involved a rendering engine optimization I recommended in a thread. I was certain it would improve performance based on reasoning that sounded technically sound. I had never benchmarked it. Someone posted results showing it made things 40 percent slower on their setup. I deleted my comment and said nothing else. That silence was the right call. Here is how I actually apply the filter now, in practice. It is not dramatic. It is mostly just slowing down.

Before writing anything public, I ask two questions. First, can I point to the source of this claim? Not a blog post I read, not a Twitter thread, but the original documentation, the paper, the test results, the physical thing itself. Second, if someone pushed back hard on this claim, would I be able to defend it or would I be making things up as I went along? If the answer to either question is uncertain, I either do the work to find the evidence or I remove the claim entirely. I do not write hedged statements as a compromise. Hedging is just confession dressed up as diplomacy. It reads poorly and it does not help anyone. I also keep a running document of claims I have made publicly and the evidence behind each one. This is boring. It is also the only thing that has kept me from repeating mistakes. I have caught myself three times in the last year simply by reading back what I had written before posting it. Two of those involved me misunderstanding a concept so thoroughly that my explanation was wrong on its face. The third was a outdated detail from documentation that had changed in a recent release. Writing the evidence down forced me to actually look at it instead of trusting my memory. There is a specific edge case that trips people up, and I hit it directly. You read something in official documentation and you repeat it as truth. The documentation turns out to be wrong or describing a deprecated behavior. This happens more often than you would think. I encountered this with a hardware abstraction layer where the manufacturer's docs described a register layout that did not match the actual silicon revision we were working with. The docs were internally consistent and professionally formatted, which made them extremely convincing. We spent two days debugging a issue that turned out to be caused by following the documentation blindly. The workaround was simple but humbling: I stopped treating documentation as authoritative and started treating it as a hypothesis. I wrote a small test program that read the actual register values and compared them to what the docs said. The mismatch was immediate and obvious. The documentation was correct for an older revision. Nothing dramatic happened. I just updated our internal reference and moved on.

Another pattern I notice is the difference between a personal observation and a general rule. "This approach worked for me" is a factual statement about your experience. "This approach works" is a claim about reality that requires evidence beyond your single data point. I used to blur this line constantly. Now I mark it explicitly. When I write something, I label whether it is a direct observation, a reasonable inference, or a guess. The labels are not fancy. They are just: observed, inferred, or uncertain. This takes about ten extra seconds per claim and it changes how people read your work significantly. Readers know what weight to give each statement. The downside of this approach is that it makes you slower. You will publish less. Your posts will sometimes be shorter because you remove the speculative sections. This feels like a loss at first. It is not. The versions you do publish carry more trust because they have been filtered. People who read your work regularly start to learn what kind of signal they are getting. That reputation compounds over years in a way that volume never does. There are also cases where the filter is too aggressive and you end up saying nothing useful at all. This is real. I have situations where I know enough to give a decent direction but not enough to be certain, and the strict filter would force me to stay silent. In those cases I say what I know and I say explicitly what I do not know. "Based on what I have seen, X tends to happen, but I have not tested Y, so I could be wrong about that." This is honest and it is still useful. It is not the same as stating speculation as fact, and it gives the reader information they can act on.

The principle is not about never being wrong. You will still be wrong occasionally. The point is that you build a system that catches you before you present something uncertain as certain, and it builds a track record that people can rely on. The fish in the book swims away confident. The hat is obviously not his. The reader knows this immediately. That is the standard I aim for now.