The Field Guide to Understanding Human Error
by Sidney Dekker · first published 2006
77% recommend23% neutral
Why HN recommends it
Approachable, example-rich look at why blaming individuals for accidents stops learning, drawn from aviation and manufacturing. Suits engineers writing blameless postmortems or designing systems that resist misuse.
Summarised by Claude from recommending comments
Affiliate links. As an Amazon Associate I earn from qualifying purchases.
Mentions per year
What Hacker News says
Related books
2018–2025Just Culture
Sidney Dekker
Recommended by 3 · mentioned by 53 recommend · 5 mention3 recommend · 53 recommend
Engineering a safer world
Nancy Leveson
Recommended by 14 · mentioned by 2014 recommend · 20 mention14 recommend · 2014 recommend
2013–2025Drift into failure
Sidney Dekker
Recommended by 7 · mentioned by 127 recommend · 12 mention7 recommend · 127 recommend
2014–2025How Not to Be Wrong
Jordan Ellenberg
Recommended by 20 · mentioned by 2420 recommend · 24 mention20 recommend · 2420 recommend
2009–2026Normal Accidents
Charles Perrow
Recommended by 44 · mentioned by 5444 recommend · 54 mention44 recommend · 5444 recommend
2010–2026Out of the crisis
W. Edwards Deming
Recommended by 24 · mentioned by 3624 recommend · 36 mention24 recommend · 3624 recommend
2013–2026Surfaces and Essences
Emmanuel Sander
Recommended by 14 · mentioned by 1814 recommend · 18 mention14 recommend · 1814 recommend
2011–2026Ways of Seeing
John Berger
Recommended by 24 · mentioned by 3324 recommend · 33 mention24 recommend · 3324 recommend
I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify…
on “We lost 54k GitHub stars” ↗…superior, two feelings I have been known to enjoy. But it's a fundamentally bad way to approach analyzing safety issues. For those who really want to dig in on the topic, I strongly recommend Dekker's "A Field Guide to Understanding 'Human Error'": https://www.amazon.com/gp/product/B00Q8XCSFI/ref=dbs_a_def_r... It's nominally about examining airplane crashes. But he breaks down into great detail why the default analytical model is entirely inappropriate…
on “Pixel sent to Google for replacement. They used it to post wife's nudes online” ↗…I highly recommend: - For basic practices: Google's SRE chapters on incident management [2] - For the history of why we prepare for incidents and how we learn from them effectively: Sidney Dekker's Field Guide to Understanding Human Error [3] [1] https://kintaba.com [2] https://sre.google/sre-book/managing-incidents/ [3] https://www.amazon.com/Field-Guide-Understanding-Human-Error...
on “Fundamentals of Incident Management” ↗I'm almost done with The Field Guide to Understanding Human Error: http://www.amazon.com/Field-Guide-Understanding-Human-Error/... It's a brilliant book written by Sidney Dekker, a "Professor of Human Factors and Flight Safety". The basic point is that the default…
on “Ask HN: Which book are you reading these days?” ↗…Controlling and blaming are terrible for creative work, though. And they're also terrible for increasing safety beyond a certain pretty low level. (For those interested, I strongly recommend Sidney Dekker's "Field Guide to Understanding Human Error" [1], a great book on how to investigate airplane accidents, and how blame-focused approaches deeply harm real safety efforts.) So it's great to see Slack finding a way to scale up without losing something…
on “Moving Fast and Securing Things” ↗Blameless postmortems work phenomenally at Etsy which is a pretty low risk setting (after reading Sidney Dekker's book The Field Guide to Understanding Human Error [highly recommended] I would say that blameless post-mortems are even more important in a high-risk setting). Except failure isn't the correct word - the book makes the case that these are natural artefacts…
on “Rules for Developing Safety Critical Code [pdf]” ↗Nicely done. Good job avoiding retrospectively blaming people and instead focusing on future system improvements. (For those wondering why this is important, Sidney Dekker's "Field Guide to Understanding Human Error" is a mindblowing book.)
on “Stripe – Outage postmortem” ↗…doesn't sound obvious to me. Most things are obvious in retrospect. But it's a mistake to confuse your after-the-fact perspective for what was going on at the time. (For those who are interested, Dekker's "Field Guide to Understanding 'Human Error'" is a great look at how subtle and dangerous that confusion can be.)
on “Growl in Retirement” ↗…anything. Indeed, it can prevent the fixing of things because, having blamed someone, we mostly stop looking for useful lessons to learn. If you want the book-length version of this, Sidney Dekker's "Field Guide to Understanding Human Error" has a great explanation of why retrospective blame ends up being immensely harmful: http://www.amazon.com/Field-Guide-Understanding-Human-Error/...
on “'I've never seen anything like it': Airbnb renters leave Calgary home trashed” ↗…smart/superior. But its universal applicability is a hint that it's not going to actually solve many problems. If you'd like to learn why and what the alternative is, I strongly recommend Sidney Dekker's "Field Guide to Understanding Human Error": https://www.amazon.com/Field-Guide-Understanding-Human-Error... His field of study is commercial airline accident review, so all the examples are about airplane crashes. But the important lessons…
on “In Bungled Spying Operation, NSA Targeted Pro-Democracy Campaigner” ↗Ooh, that reminds me of another excellent book on failure, Sidney Dekker's "Field Guide to Understanding Human Error": https://www.amazon.com/dp/1472439058 It's about investigating airplane crashes, and in particular two different paradigms for understanding failure. It deeply changed how I think and talk about software…
on “Structural engineers are unsung heroes” ↗John Allspaw applied concepts from The Field Guide to Understanding Human Error to software post mortems. When I was at Etsy, he taught a class explaining this whole concept. We read the book and discussed concepts like the Fundamental Attribution Error. I've found it very beneficial,…
on “Amazon cargo plane crashes in Texas” ↗…back then that if you just ramped up punishments, things would get better. Turns out they didn't. Anyway, to save you from getting it from an inferior source (me), I'll give you some good ones: - The Field Guide to Understanding Human Error by Sidney Dekker - The Challenger launch decision : risky technology, culture, and deviance at NASA by Diane Vaughn You don't have to but you can also read how the FAA only pursues civil actions in…
on “Uruguayan artist blacklisted by PayPal because her name contains “iran”” ↗…satisfying, and often status-enhancing. It's also going to make the world less safe, because it prevents us from solving the actual problems. Those serious about reducing failures should read Dekker's "Field Guide to Understanding 'Human Error'": https://www.amazon.com/Field-Guide-Understanding-Human-Error... It comes out of the world of airplane accident investigations. But so much of it is applicable to software. The first chapter alone,…
on “A Docker footgun led to a vandal deleting NewsBlur's MongoDB database” ↗Sidney Dekker's _The Field Guide to Understanding 'Human Error'_ has a bit about this (which he calls drift). One thing I liked in that section is a sort of anti-Murphy's Law: What can go wrong will usually go right, and then we'll assume that it will go right again…
on “How Completely Messed Up Practices Become Normal” ↗