Book review: The Checklist Manifesto(lesswrong.com) |
Book review: The Checklist Manifesto(lesswrong.com) |
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.
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.
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.
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).
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.
1. adjusting the paper thickness
2. adjusting the font size
3. adjusting the line spacing
4. adjusting the margins
5. adding blank pages
The actual amount of text in a book varies dramatically.
One of the few actually good business books (Crossing the chasm) is a single drawing!
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 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.
Another failure of the attention economy.
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.
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).
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.
But pilot checklists are written by pilots. Who knows who writes EHRs' checklists?
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?)
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.
It's kinda nice and funny and definitely gets the job done as lives depend on making sure all locks are secured.
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.
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
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.
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.
> 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.
- https://www.lesswrong.com/posts/S69ogAGXcc9EQjpcZ/a-brief-hi...
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.
Thanks too for the circle-slash system, I'm pinching that.
https://www.e-publishing.af.mil/Product-Index/#/?view=search...
The guidelines for updating are in there, as well, I believe.
One example of a software firm in this space: https://www.fieldlogs.com/FieldLogsStatic/index.html
If you are serious about X, you do indeed need an X culture, but you get that by making it everyone's job to do X.
Creating an X department staffed with X people will have the exact opposite outcome.
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.
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.
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.
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.
(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.)
“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.
So I know Refactoring UI did ridiculously well (https://twitter.com/adamwathan/status/1289702466754211842) for example while being concise.
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.
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.
Such indecisiveness heh.
Yeah, that’s getting cribbed for sure!
A disposable piece of paper and an ink pen? Confluence seemed to have a PDF export button so I assume it's possible.
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.
To create a check:
@bugout-dev check require <message>
To mark it as complete: @bugout-dev check accept <message>If it takes repetition or length to do it, so be it.
Some books even recommend you read them a second time for that purpose, like Getting Things Done and How To Win Friends and Influence People.
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.