Working Backwards From the Wreck

He called it inversion. It sounds clever, but it's really just common sense turned around. Most things that go wrong on a website were never asked about beforehand. Nobody plans a confusing donation form. Nobody decides to lock a screen reader user out of the homepage. Those things happen because nobody stopped to ask what would break first.

Munger had a second habit that went with it. He never stuck to one field. He'd pull an idea from psychology, another from engineering, another from biology, and use whichever one actually explained the problem in front of him. He called it a latticework of models. The idea is simple: look at a problem through only one lens, and you'll miss whatever that lens can't see.

If you want to go deeper on the models themselves, Farnam Street has built a proper library of them at fs.blog/mental-models.

A website works the same way. It's never just a design problem or just a code problem. It's people, systems, and money, all living on the same URL. Ignore any one of those and it comes back to bite you later.

Engineering: build for the bad day, not the good one

GitHub went down for over seven hours on the 17th of August (2026). Thirteenth outage that month. The reason: AI coding tools were sending roughly thirty times the traffic the system was built for.

Thirty times isn't a small miss. It's what happens when nobody asks, early enough, "what happens if this gets hammered harder than we planned for?" Engineers build in spare capacity for exactly this reason: "we didn't see that coming" doesn't hold up once something's actually broken.

But you don't need GitHub's scale to feel this.

Working on a donations interface, part of what I've been building was a place to store the actual donation data. Picture it holding ten million donation records two years from now. If the nightly job that finds which ones are due has to scan every single record to find them, it gets slower every year, until one day it doesn't finish before the next one starts. So we built an index instead. The job goes straight to today's due donations without touching the other 9.99 million.

Nobody asked us to think that far ahead. We just asked what would break it first.

Psychology: you can't fix what you can't see

WebAIM runs an annual scan of the top one million homepages on the web. Their 2026 report found that 95.9% of them have a detectable accessibility problem. That number has gone up, not down, even though awareness of the issue has never been higher.

Someone approved every one of those homepages before it went live. Most of them probably looked fine, because the person approving it was looking at a screen with their eyes and clicking with a mouse. Turn on a screen reader instead, the way a visually impared visitor would have to, and half the buttons on the page might just say "button", with no idea what they actually do. You only catch that by using the thing the way someone else has to.

The same report found something else. When a US compliance deadline got pushed back a year, plenty of organisations that had been scrambling in spring just relaxed by summer. Nothing changed for the people actually struggling to use the site. Only the pressure did. It's a pattern that shows up whenever the reason for doing something is a deadline, not a person.

The one question worth asking

You don't need a new process for this. Just one extra question, asked earlier than usual, whatever you're working on.

Skip "will this work?" Ask instead: who does this fail, and would I even notice?

Ask it of the donation form, and you're checking what happens when someone's card gets declined. Does the message make them feel like they did something wrong, or does it just say try again? Ask it of a new content block, and you're checking whether an Editor who's never touched it before can use it without messaging you for help. Ask it of a redesign, and you're checking who's coping just fine on the current site, and would stop coping the day the new one ships.

That's the whole trick. Most bad outcomes are avoidable. You just have to ask what would go wrong before it does.