Working beliefs
Things I believe
Five working beliefs about building software. They’re not fixed: they change as I learn, and when they do, this page changes too.
Last updated 10 August 20261. Software that fails should fail loudly and safely, not guess.
A result that looks plausible but is wrong does far more damage than an honest error. When my code meets something it doesn’t understand, I want it to stop, say exactly what went wrong, and leave things in a state someone can recover from.
2. The database is the source of truth; messages are hints.
A message tells you something probably happened, or ought to. What actually happened is whatever got committed. I write consumers that check the record before acting, so a duplicate or out-of-order message can’t quietly rewrite history.
3. Never trust model output you haven’t checked.
Language models are very good at producing things that look like answers. In my extraction pipeline every fact a model pulls out is verified against the source document before it’s accepted, and anything that can’t be verified goes to a person.
4. Boring technology, carefully composed, beats clever technology.
Queues, relational databases, plain HTTP and well-understood auth will carry most systems a long way. The interesting work is in how they fit together: retries, timeouts, and who owns each piece of data.
5. If you can’t observe it in production, it isn’t finished.
Shipping is where you start finding out whether something works. If I can’t see its logs, metrics and failure states once it’s live, I haven’t finished building it. I’ve just stopped looking.
Disagree with one of these? I’d genuinely like to hear why.
hello@joshuaashton.com