On Writing Things Down
The habit of writing — not publishing, just writing — is one of the most underrated tools in a developer's toolkit.
I keep a running document I call “the dump.” It’s ugly, unorganized, and I’ve never shown it to anyone. It’s also where most of my actual thinking happens.
The dump is not a journal. It’s not a note-taking system. It’s closer to a whiteboard — a place to put half-formed ideas before they dissolve. I write in it the way I think: in fragments, with tangents, without worrying about whether it makes sense to anyone else.
The result, over time, is that I have a record of how my understanding of things has changed. I can look back at notes from two years ago and see exactly where I was wrong, and why.
Why developers should write more
We already know this at the code level. Comments, commit messages, ADRs — we’ve built an entire culture around writing things down when it comes to code. But when it comes to thinking? Most of us just… keep it in our heads.
The problem is that our heads are bad at it. We’re not good at holding complex, ambiguous problems in working memory and reasoning about them reliably. Writing externalizes the problem. It gives you something to push against.
The act of writing “here’s what I think the issue is” forces you to actually know what you think the issue is. More often than not, you realize mid-sentence that you don’t.
The key insight: write to think, not to publish
The mistake I made for years was conflating writing with publishing. I’d start something, decide it wasn’t good enough, and abandon it.
But publishing is one thing. Writing is another. Most of what you write shouldn’t be published. It’s a tool for thinking, not a product.
Once I separated those two things, writing became much easier. The dump has no quality bar. It’s not for anyone else. It’s just for thinking.
What this looks like in practice
- Before a hard conversation, write out what you want to say and what the other person might say back.
- Before a big technical decision, write out the options and what you’d lose with each.
- When you’re stuck on a bug, write out what you know and what you don’t know.
- When you read something good, write a sentence about what you took from it.
None of this needs to be published. Most of it won’t be. But the thinking that happens in the act of writing will show up in the work — in clearer PRs, better explanations, more confident decisions.
The dump is where this blog post started, incidentally. It began as four scattered lines in March and slowly became something coherent. That’s usually how it goes.