← Writing

reading the diff

· 3 min read

Every software project has two information layers.

The announcement layer: blog posts, tweets, changelogs written for marketing. What the team decided you should know. Edited, sequenced, narrated for maximum reception.

The diff layer: what actually changed. Unfiltered. Every line added or removed. The commit message written at 2 AM when nobody was thinking about brand voice. The function renamed three times before they settled on something. The test that got deleted. The comment that stayed in the code but didn’t make it into the changelog.


Most people read announcements. A smaller group reads diffs.

The announcement tells you what they shipped. The diff tells you what they were trying to build, what they abandoned, what they’re not sure about yet, and sometimes — if you read enough of them — what they’re about to announce next quarter.

Diffs don’t know they’re being read. That’s the thing. A product team can control every word in a press release. They cannot control what the git history reveals about how many times they rewrote the same function, or which features got quietly removed the day before launch, or which dependency got added three weeks before the acquisition was announced.


This isn’t about finding bugs or exploiting leaks. It’s about epistemics.

The announcement layer optimizes for reception. It’s compressed toward the most favorable interpretation of the work. That’s fine — projects need to communicate, and communication requires selection. But you can’t use curated information to calibrate accurately. You’ll end up with everyone else’s model of the project, which is the model the project wants you to have.

The diff layer is adversarially honest. It records what was hard. Where they got stuck. What changed direction. What the actual sequence of decisions was, rather than the post-hoc narrative that makes it look inevitable.

Projects that are doing well and projects that are pretending to do well look similar in their announcements. They don’t look similar in their diffs.


The ratio matters.

A project with a lot of announcement and a thin diff history is building narrative. A project with a quiet announcement layer and steady diffs is building something. The ratio between how much they say and how much they ship is more signal-rich than either alone.

I don’t think most people read diffs because it’s slower. You can skim an announcement in ninety seconds. A meaningful diff takes twenty minutes of actual attention — following the thread, understanding what was there before, reconstructing the decision from the change.

That friction is the moat. If it were easy, it wouldn’t be edge.


Most useful information in technical domains is available and ignored. Not because it’s hidden — it’s public, in most cases literally open source — but because reading it correctly requires a different kind of attention than most people are training.

Read the announcement if you want the story they’re telling. Read the diff if you want to know what’s happening.

The gap between those two is where most of the edge sits.

Related