I liked this book, but it’s a prime example of an article or blog post that gets turned into a book by adding a bunch of things that don’t really provide more useful information, but seem to serve as filler to make it book-length.
I read the book, and I read the article that the book was based on. I don’t recall learning anything from the book that I hadn’t already learned from the article.
Welcome to the genre of self-help books. I can't recall the last one I read that couldn't have just as easily been a long essay. "Here's a few good points and ideas, surrounded by a fuck-ton of anecdotes and proverbs, because you're not going to pay $20 for a magazine article."
> "Here's a few good points and ideas, surrounded by a fuck-ton of anecdotes and proverbs, because you're not going to pay $20 for a magazine article."
Though to be fair, sometimes those anecdotes are useful. I like examples, especially ones where an idea is applied to a situation that resembles my own. Also repetition is helpful to actually have a concept sink in.
Also, what's filler for you may be the most relevant section for someone else (e.g. an anecdote that matches their situation but not yours, or necessary repetition).
Also, I think software engineers, at least, have a bias to optimize for concision that can sometimes be counterproductive. For instance, I doubt a moderately long article that fully explains the core concept of cognitive behavior therapy would be as successful at actually changing the behavior of a depressed person than a more "redundant" book-length version. Maybe the short version would still work for some people, but that doesn't mean that's the best version for the majority of people.
I think for the layman, those anecdotes that strike on pathos are what sticks. I remember the stories about patients who avoid mishaps through checklists that caught the wrong limb being marked and their (understandably) irate reaction more than statistics.
I actually think this book is one of the rarer examples where the various stories and anecdotes that are sometimes seen (rightly) as “padding”, are actually in this case quite effective at getting the message across in quite a memorable way.
It’s been a while since I read it but I seem to recall a lot of similarly effective stories about airline pilots too.
A charitable view I hold on days when my mood is good is, for each of us at any given point in life, there exists a magic sequence of words that will make a concept stick. That may be a story that hits one "right in the feels". That may be a sentence, the right sentence, that makes a complex concept finally click in one's head. So all those books, each talking about the same thing, each repeating an article's worth of content 200 different ways - they're maximizing the amount of readers that find the magical uttering, for whom it all falls into place.
On regular days with regular mood, I say it's just easy way of milking people, and that self-help genre died soon after being born, i.e. back in the days of Dale Carnegie.
Last year I heard someone call out the value in your mind being exposed to a topic for a length of time. I've found this to be true. I recently reread The Art of Motorcycle Maintenance and forming my own mental model and brushing it against what three book had to say gave me more value than just absorbing the book's content.
I'm so so immensely relieved to learn I'm not the only one feeling this things.
Happened with all the self-help or self-improvement books I've touched.
The most excessive example of this being "getting things done" which was very trendy about ten years ago: the first third of the book were literally about the author bragging about results (but without any way to fact-check).
> it’s a prime example of an article or blog post that gets turned into a book by adding a bunch of things that don’t really provide more useful information, but seem to serve as filler to make it book-length.
I've seen solo technical authors trying to sell concise ~100 page books and you often see comments like "that's too expensive, you can read it in a few hours and ebooks don't cost anything to produce!", ignoring the value of the information and how it's much more effort to be concise over verbose. I can see why there's a pressure to stretch text out to make it monitisable.
Are there good examples of authors making money from very short books or articles? I'm amazed there still isn't a web microtransactions solution yet so e.g. blog readers can tip a small amount with no effort so concise + valuable information can be monitised and encouraged.
This is a plague on business books too, which are generally papers -- but who's going to buy a 10 page book from an airport bookshop? So they get padded on on autopilot.
One of the few actually good business books (Crossing the chasm) is a single drawing!
I disagree. The most interesting bits for me were the examples of application where things differed from my expectation. Construction checklists that included items of the form "Person A talks to person B" is the example that comes readily to mind.
The worst thing about the book is all the self-congratulatory back patting, but I think that's comparably present in the article. I still often recommend the book.
The problem is that you can easily read a concise article, nod your head, understand it, and then entirely forget it.
With a book, you get the main ideas presented multiple times, applied, examined, refined, put in context, etc. Now, you’ll also forget all that apparently extraneous stuff, but at least you’ll remember the main ideas.
I find myself wavering back and forth. Great fiction? Give me a big cinderblock of a book please. Full of world building and chapters dedicated to a single thread of thought going through a character's mind. Even to the point of sometimes when reading short fiction novels getting anxious towards the end, just knowing the ride is almost over.
Non-fiction/fact-based/instructional books I flip-flop hard between enjoying a brief enchiridion on leadership and management styles one moment while cradling a tome of a physics text book the next.
As somebody who also read the book, I recommend the book but totally agree. There are some interesting anecdotes in there but many are more interesting than persuasive. The book could have been half its length. I use checklists a lot and didn’t learn as much as I would have liked
It's been a few years since I read it, but my recollection is that it presented the same information as the article, but added a bunch of additional studies and supporting arguments. Which didn't add any value at all.
Having read the book, I fully agree. Atul Gawande is obviously a smart guy, and the book is very readable, but I gained almost nothing from reading it that I couldn't have gained by just reading the LW article linked in the OP. Not recommended.
agreed. i read this book on recommendation several years ago and felt it could be distilled in a blog post and i probably would have gotten more out of it.
Because usually it doesn’t. It usually boring redundant content where you have to dig for the point.
The same is true for many articles: what I needed was a picture and a caption, what I got was 2000 words which didn’t add much at all.
Good writing of this kind makes its point right away and invites you to read more to expand on the point instead of holding the main idea hostage for most of the piece.
Because with less padding, people could spend the other 180 pages reading about 9 other ideas.
Naturally, I know that's not so simple, but it is one of the key issues I have with books that say the same thing over and over again — lack of respect for the reader.
Books like this, IMO, are generally better when split into 2 pieces:
1. A "core" that describes the motivation for the ideas and then the ideas (as in, what makes a checklist, how comprehensive do they need to be, basic ideas on how to store and maintain them).
2. An expanded form, providing more detail on the motivation (issues that could have been mitigated if not eliminated with checklists, areas where checklists have succeeded, more specific practices around checklists that worked for some people, for the reader's consideration).
This lets you skip the fluff if you've already been persuaded by going with (1), or if you need to be persuaded or want ideas on how to persuade others going with (2). A lot of useful material ends up suffering from self-obfuscation by only providing or too strongly pushing (2) and not (1).
Since there is the New Yorker article, in this case both (1) and (2) exist (after a fashion, it's been a few years since I read that article so I'm not sure anymore what's in it but it is much briefer than the book).
If he had only written the book, I likely wouldn't complain. But the fact that he accomplished the goal - convincing me that checklists were awesome - in a much shorter article, tells me that the rest of the book was unnecessary.
Gawande mentions the checklist libraries of different manufacturers. I've checked the references (and parts of the citation graph) but didn't find anything about them. The closest were NASA's standards about the typography and structure of flight deck checklist. Does anybody know about how are checklists managed in the real word? How are they stored, retrieved and most importantly updated, when something changes? Not theoretically. from first principles, but like, at the manufacturer?
In the fanciest systems, checklists live in a computerized procedure system tied into the plant process computer, so the plant state and procedures can be kept in sync and mistakes can be avoided when the software can see if you didn’t actually do the step you were supposed to.
A more conventional approach is a document management system and controlled binders in the control room with the latest procedures, often laminated so they can be marked up and wiped off.
When working procedures on paper, we always use a circle-slash system for place-keeping: circle the step number when starting it, and slash through the circle when completed.
Finally, key procedures should have a separate document documenting the bases of the procedure—-why key values were chosen or what other documents they were taken from or depend on. That document becomes the key in change management—-if a dependency changes, or you want to change the procedure, you can use the bases document to ensure side-effects are considered.
Finally, procedures still have programmed regular reviews.
Not manufacturers, but here's the USAF's collection of checklists (not complete, bases and smaller units will have their own libraries that may not make it into this):
A better example is aviation, especially commercial. Planes come with Pilot Operating Handbooks (POHs) that contain checklists specific to the aircraft for preflight, inspection and failure scenarios (eg loss of engine power). Manufacturers periodically update these by issuing advisories and addendums to POHs. The FAA also publishes such advisories.
There’s a scene in the movie “Sully” that occurs right after the bird strikes that I’ve seen a few people in commercial aviation respond very positively to in its depiction of checklists during a crisis moment.
There are firms that specialize in software to do exactly what you’re describing. But a lot of it is just cultural. For example, how do you make sure checklists are updated? You hire people whose sole job is to update checklists.
It’s been awhile since I’ve read it but I believe the book touched on the cultural piece. One of the unique things about aviation is that there culture if checklists starts with neophyte pilot and continues through their career.
Many other domains have checklists but not the cultural element. When it’s not engrained, you run into a lot of “I don’t need a checklists, I know what I’m doing.”
IMO the culture piece is the real tough problem to solve.
Amazingly enough, most fields where death from mistakes is common, other than aviation and medicine, still do not use checklists. And, even most hospitals still don't, or do only in some places.
Police don't, anywhere I know of. Probably a few fire crews do (I bet mainly at airports).
Arguably, not using checklists, or even just not using one that one time, should automatically cause the defendant to lose any wrongful-death lawsuit.
> Making a good human-usable checklist takes a lot of workshopping. Airlines are still constantly revising their 200-page manual of individually optimized checklists for every possible emergency, as plane designs change and new safety data rolls in.
When I first read the book a couple years ago, and introduced checklists into my team, I found that there was no great tool to manage and create checklists and share it with my team. We were basically copy pasting messages over and over in Slack and "checking" them off manually by editing the message. Is there a tool or SaaS out there that solves this problem? (If not, great startup idea?)
Most project management systems have methods for dealing with checklists, this is definitely not what slack is designed to do no matter how much they market it as a "productivity tool"
So if you're not using something for project management first you need one of those, but just about everyone does, and once you have one you can start using it's checklist features
Then it depends on what that specific software offers, but even if it doesn't have a true feature for creating "templatized checklists" which I assume people want so they can repeat the same list, most have duplication functionality so you can just create one as a template and duplicate it as needed.
Is there a way to use checklists in Confluence in a way that's not terrible? My team has a checklist we go through regularly and have to use Confluence for this sort of thing. While you can make checklists in there, we can't find a way to make the check marks ephemeral. Every single time someone checks an item it updates and saves the page. We also can't find a "clear all" button. So every time we go through the checklist someone has to manually uncheck every single item, or forget and just leave some checked for the next time.
The best option I've found is to hack in a little bookmarklet to uncheck all of the items with a click. It works for now, but I've done this to fix other Atlassian annoyances in the past and they usually churn the html enough that the scripts regularly need to be updated.
Google Docs has introduced checklists alongside unordered and ordered lists.
The keyboard shortcut to start a checklist is CTRL + SHIFT + 9.
Blew my mind when a friend told me about this.
Edit: Also, for software teams, GitHub supports checklists on their issues/PRs. My team has written a bot which blocks PRs until all checks are checked off. It's been pretty fantastic.
The markdown in github is damned annoying, though, it's whitespace-sensitive in THREE separate places (after the dash, between the brackets, after the brackets) - and then when you are saying "I did this" you have to add the x and delete the space between the brackets. I realize it sounds nitpicky but if you're really using checklists for everything then micro UX like this matters.
(I'm sort of hoping someone corrects me on this point & I find out a better way to use it because I do love the functionality, in theory, I just find myself never bothering to check off anything is completed.)
I've also found this behavior annoying. There should be no difference between "-[]", "- []", and "- [ ]". There should be no difference between "- [x]" and "- [ x ]".
The solution we came up with is, for people who want to use the Web UI, GitHub has clickable checklists. For people who don't like the Web UI, we have commands.
“Process Street is a simple, free and powerful way to manage your team's recurring checklists and procedures.” No affiliation, just interested in the same problem.
Looking through the feature set I don't see repeatable, templated checklists as a feature. Every app has normal checklists nowadays, but there are basically no solutions for repeatable ones (which is what the article/book are talking about).
obsidian is great for both notes and checklists. It allows you to have a simple checklist up front, but with clickable links that hide as much (multimedia) information, internal and external links as you need.
The best thing in this book is all the information on how pilots have checklists for everything. The plane that landed in the Hudson is used as an example and the checklist for total engine failure used in the book is one of my favorites.
In big bold letters at the top is "FLY THE AIRPLANE" along with each of the things the pilot should check.
Takeaway is the reminder in the moment that you are trained for this and the checklist itself is exactly what checklists are for -- don't miss a step. Nothing more, nothing less.
On a related note there is a bungee jumping spot in Taupo where the guys harnessing you sing like a small song which has lyrics of a checklist to make sure every lock is secured (They test each lock at the appropriate lyric)
It's kinda nice and funny and definitely gets the job done as lives depend on making sure all locks are secured.
Much of the elaboeate gesturing that is done by Japanese train drivers and platform staff is them mentally ticking off items. The movements makes it rote. So no need to recall the next step which is embedded in muscle memory.
It's more than a checklist - it's called "Pointing and Calling" and it's both to draw more attention for yourself and for communication with others involved.
I've been using https://buckaroosoftware.com/ChecklistWrangler.html for years now on my phone for my personal checklists. It's got way more features than I need (and hasn't been updated in years) honestly even checking things off the list is probably overkill and I could just use a text file, but its the only thing I found on the App Store that actually did a checklist instead of a task list. I've got drawings for a very simple checklist app but it's not become a side project yet.
Somewhere in my unassorted notes, there's a sketch of a checklist app too, made right around the time I read "The Checklist Manifesto". My experience is the same: everyone does task lists. Nobody seems to be doing checklists - sequences[0] of tasks that repeat ad infinitum, evolve over time, and need to be surfaced based on situational context.
--
[0] - Actually not sequences, and not trees, but directed acyclic graphs. But this isn't the right time and place to go on a yet another rant about how none of the "hot" players in task management have figured this out.
Legitimate question, is there enough interesting information in this book worth reading if you already agree with the premise, that in complex situations checklists can be good?
I've known about it for awhile and this review does a good job at providing a real-world example of where it's useful, so other than ideas of how to make good checklists I'm not sure if actually reading it is something I should do
It completely changed the way I work. I'm now a checklist making machine and I find it helps so much, not only with clearly defining what I'm aiming to do, but also with motivation, as each checkbox is a very small bitesize chunk that always seems manageable. I recommend giving it a shot. It's really short aswell so you could smash it out in an afternoon.
If you have the means to "waste" money on the price of the book, I'd recommend it. But by "waste", I mean that the book could have been a thick pamphlet, but publishers sell books and not pamphlets, so by golly that essay is going to get the shit fluffed out of it until it is book-length. So you're paying for a lot of marshmallow cream.
That said, the premise is good and you might glean some good practices that you'll put to use. It's just that it's not worth the $15, IMO. If you have disposable income, buy it. Otherwise, just go read the New Yorker article referenced elsewhere in this thread.
So I was following the service manual for changing oil in my wife's car. From memory it was something like this:
1. Place drip pan belo
2. Remove plug & drain
3. Use wrench to remove filter
4. Place new filter in
5. Replace plug
6. Unscrew oil fill port cap
7. Add 5 quarts of oil
8. Run engine for 5 minutes
9. Top up oil until level is correct as indicated on dip stick
Notice there is an important step missing between #7 and #8 (replacing the oil fill port cap). I think I changed the oil twice with no issue before I made that mistake and sprayed oil everywhere. I wrote up my own instructions that broke it down into smaller steps and didn't omit any after that.
I remember reading an article some time ago about some people who inspected power lines from a helicopter. They introduced check lists and the number of accidents increased. It related to them no longer going through the plan as a team and absently mindedly checking off the list without thinking about it properly. My search skills are failing me and I can't find it anywhere.
> In 2015-2016 the site underwent a steady decline of activity leading some to declare the site dead. In 2017, a team led by Oliver Habryka took over the administration and development of the site, relaunching it on an entirely new codebase later that year.
> The new project, dubbed LessWrong 2.0, was the first time LessWrong had a full-time dedicated development team behind it instead of only volunteer hours. Site activity recovered from the 2015-2016 decline and has remained at steady levels since the launch.
I read the book, and I read the article that the book was based on. I don’t recall learning anything from the book that I hadn’t already learned from the article.