[HN Gopher] Checklists are hard, but still a good thing
___________________________________________________________________
Checklists are hard, but still a good thing
Author : zdw
Score : 69 points
Date : 2025-07-20 15:51 UTC (3 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| devenson wrote:
| Is the checklist complete? If not, it might lull you into a false
| sense of security. How do you know if it's complete or not?
| NewEntryHN wrote:
| Would't any additional item increase safety?
| ceejayoz wrote:
| No, not if you overdo it. You start getting into
| https://en.wikipedia.org/wiki/Alarm_fatigue territory.
| 0x457 wrote:
| If your checklist is PITA to got through, then completing it
| will more like to lure you into that false sense of security
| that you might even miss something obvious.
|
| IMO the best way is to start small, and every time checklist
| didn't catch an issue either modify existing item(s) or add
| new item(s). Organic complexity is the best complexity.
| kragen wrote:
| Clearly you need a checklist for making checklists.
| massysett wrote:
| The checklist doesn't have to be perfect. Just continually
| improve it.
|
| I keep several checklists - some I use several times a week,
| others every few months or so. If I notice something needs to
| be added to the checklist or removed, I do so.
|
| It's always better to start with an imperfect checklist vs not
| having any checklist at all. With no checklist, you start from
| scratch every single time. Not starting from scratch allows you
| to focus on marginal improvements with each use.
| ethan_smith wrote:
| A checklist is never truly "complete" - treat it as a living
| document with a built-in review step that asks "what did we
| miss?" after each use.
| spc476 wrote:
| I did this at a previous job for running a complicated
| regression test (that couldn't be fully automated for
| reasons). I initially did this for myself as the regression
| test wasn't run that often. I also made sure that anyone new
| to the department would have to run the regression test and
| report/update with any missing steps.
| autoexec wrote:
| "Update checklist if needed" should be the last thing on
| every checklist!
| vorgol wrote:
| That's just like saying that if no tests are failing then we
| don't have any bugs.
| dvt wrote:
| Checklists are criminally underused in most industries. It's a
| testament to how great they work when looking at highly-
| antifragile contexts: aviation, military, etc., where a mistake
| can (and often does) cost lives.
|
| The problem is that to use them broadly, you also need to
| implement operational-level changes. So if I made a startup that
| helped build checklists, the problem would not just be selling
| the software (which everyone has to do), but also convincing
| executives that checklists (even moreso than to-do lists) are
| worth investing in. The friction a checklist brings, at least in
| non-ultra-risk-averse verticals, might not be worth it.
| jerf wrote:
| Heck, they're underused in general. Checklists to pack for
| vacation. Checklists for "what did I mean to do this weekend".
| Checklists for "here's what we need to run the volunteer dinner
| this organization I belong to does weekly". Checklists for
| "things to check before my presentation".
|
| I'm nowhere near as obsessed with them as that may make me
| sound; by temperament I'm definitely a go-with-the-flow sort of
| guy... which is perhaps exactly why I make sure to use them in
| certain important places. Go-with-the-flow has its strengths
| but also its weaknesses. Selective augmentation with checklists
| means I can often end up with the best of both worlds between
| that and being "detail oriented" for important tasks.
|
| I have been called "detail oriented" a few times in my
| professional career, and I sort of laugh to myself because it
| is absolutely and utterly untrue. _I 'm_ not detail oriented in
| the slightest. It's all offloaded to the computer, with my unit
| tests, checklists, and such. I just know I need that
| augmentation and am quite aggressive about getting it precisely
| because I know I need it.
| parpfish wrote:
| checklists do wonders for my anxiety.
|
| too often i'll have a sudden thought about "oh, i need to
| make sure to fix X" or "I cant forget to pack Y before the
| trip". My options to deal with those sudden thoughts are:
|
| 1. Do it immediately, which isn't always possible
|
| 2. Do it later, which means that I'll obsessively stress out
| about it because "what if I forget to do it? I need to make
| sure this stays at the forefront of my mind at all times."
|
| 3. Put it on a checklist and give myself permission to stop
| thinking about it until its time to do it
| patrickmay wrote:
| "The mind is for having ideas, not holding them." -- David
| Allen, author of Getting Things Done.
| Jtsummers wrote:
| This is one of the key concepts of "Getting Things Done".
| Getting tasks and information out of your head so you can
| actually focus on what you want to accomplish or need to
| do. GTD has a lot more to it, but this is around 80-90% of
| it with the rest being implementation details. When you get
| the idea, as you have, you can start reflecting and
| trialing different systems to see what specifically works
| for you and in what contexts.
| tonyarkles wrote:
| > Checklists to pack for vacation
|
| I often have to travel for work. Sometimes I have a fair bit
| of notice in advance and sometimes I don't. In either case,
| checklists are super handy for me. I generally use either
| Apple Notes or Obsidian for these (previously Emacs org-mode
| but it's less convenient for the "add an item from your
| phone" case than the other options).
|
| For the "notice in advance" case, I'll start a packing
| checklist pretty much the moment I know I have to travel and
| I'll immediately write down just a sentence or two about the
| purpose/objective of the trip and add any special things I
| might need (e.g. a Saleae logic analyzer for debugging or a
| GoPro for documenting). As things get discussed and the trip
| gets closer I'll keep adding things to the list.
|
| For the "not much advanced notice" case, I'll look back at
| previous checklists to find one that has a similar objective
| and basically just copy it wholesale and tweak. Super super
| useful keeping those old checklists around, even if they're
| only 80% correct for the next trip.
| jiehong wrote:
| Checklists are the first step to automation, really.
|
| Run the list manually, then automated each check point by
| point.
|
| Voila!
| wickedsight wrote:
| I've proposed using checklists at multiple jobs and people
| never want them. They always claim they're not necessary and
| add a ton of work. Then we all keep making the same mistakes
| every time.
|
| I've quit proposing them for this exact reason. Sometimes I
| just make my own.
| icelancer wrote:
| We use them at our business for travel deployments/installs.
| They must be printed, each line item must be signed off + dated
| + timestamped in the presence of another employee on the same
| travel team (who attests the signature and the work), and they
| can never be electronic in nature except for the creation +
| printing of them.
|
| Typically we have a non-traveling employee or manager do the
| final once-over and attestation, though they don't review the
| work necessarily. _(Usually they just spot check the gear being
| shipped /sent to the airport, Pelican cases, Airtag trackers,
| etc.)_ This has been helpful for organizational purposes.
|
| We don't even computerize them in any way outside of taking a
| cell phone picture of the final checklist and uploading it to a
| shared Slack channel for archival purposes.
|
| It has prevented so many problems. It also fails to prevent
| some... which get added to the next checklist.
| marcosdumay wrote:
| None of those contexts are anti-fragile.
|
| You probably don't want a lot of process reliability in anti-
| fragile contexts, like the startups you mentioned. You insist
| on reliability in fragile contexts.
| dvt wrote:
| > None of those contexts are anti-fragile.
|
| Nassim Taleb (who coined the term), literally uses the
| aviation industry as a prime example of antifragility in his
| book[1], so I think our wires are getting crossed somewhere.
|
| [1] https://www.amazon.com/Antifragile-Things-That-Disorder-
| Ince...
| tonyarkles wrote:
| Yeah, I love the book and remember that being brought up. I
| might have to go revisit that part of the book as a
| refresher. Aviation, in general and in my current mindset,
| doesn't seem to benefit from disorder the same way a lot of
| the other examples he uses in that book.
|
| Aviation is absolutely robust though.
|
| Do you happen to remember how Taleb framed aviation as
| anti-fragile instead of just robust/not-fragile? As an
| industry I suppose we're quite good at taking lessons-
| learned from failures and incorporating those lessons back
| into making aviation safer as a whole.
| chromiummmm wrote:
| What's the difference between a checklist and a todo list? Is
| it that a todo list is the things you need to do and a
| checklist is how todo one of those things?
| adolph wrote:
| The semantics of list types is an underrated problem that
| probably holds back the market of software tutorials.
|
| A todo list is typically a set of unrelated things to be
| performed once and annotated as "done." Something may be
| performed periodically, like iOS reminders adds take out the
| garbage on a weekly basis, but each performance is really its
| own item. Sometimes a todo list will have parent-child tasks.
|
| A checklist is a two lists: one a template and the other the
| record of performing the checklist. The template and
| performance instance records are a set of related things
| which may or may not be ordered or conditional. A special
| type of checklist is an inspection checklist which may
| include results from performing a particular checklist item
| as well as the fact that it was performed.
| Jtsummers wrote:
| They're similar, lists of tasks/items to check off. However,
| when most people talk about checklists they're often talking
| about it in particular contexts and a more deliberate
| construct than todo lists. Pilots, for instance, have pre-
| flight checklists. This is not an ad hoc todo list (the more
| common sense of "todo list") with arbitrary and possibly
| unrelated tasks (go to grocery store, pick up dry cleaning,
| outline paper).
|
| Checklists, especially in system operations and safety
| contexts, also tend to have a bit of a procedural
| characteristic, possibly including conditional and even
| looping constructs or sub-procedures. - If
| HPA is energized - [ ] De-energize HPA - [ ]
| Enter radome
|
| And order is important to many, but not all, checklists in a
| way that's not as clear in todo lists. You can probably pick
| up the dry cleaning before the groceries, or on a separate
| errand run, for instance. If you don't de-energize the HPA,
| you're possibly setting yourself up for some pain and
| suffering if you enter the radome while the system is
| energized.
| dvt wrote:
| I think there are two differences: urgency and immediacy. A
| checklist is urgent in a way a to-do list isn't. The sky
| _will_ fall if a checklist is not followed when X happens,
| whereas a to-do list is kind of a nebulous list of
| nondescript tasks. A checklist 's immediacy also implies a
| strict ordering, whereas a to-do list does not. For example,
| task A _must_ be completed before task B or the sky _will_
| fall.
|
| It's just a lot stricter operationally, which is why I think
| you'd get a lot of pushback trying to implement one for non-
| critical business tasks.
| contrast wrote:
| A todo list is a unique thing, it's about remembering to do
| all the things you said you'd do. There's no implied
| consistency from one todo list to another.
|
| A checklist is used repeatedly, and it's about completing a
| task (or set of tasks) to a certain standard. If you're
| following a checklist, you're aiming for consistency.
| o11c wrote:
| Checklists are usually for repeatable activities (or at least
| similar-enough ones).
| rapfaria wrote:
| Which is why programming, reality, and even recipes are so hard.
|
| Ever go try to cook something new and you read "Pre-heat the pan
| on low-medium...", and your programmer brain just can't take it?
| What kind of pan, what's low-medium on this burner, how much pre-
| heating are you talking about? These can't be all the
| instructions.
|
| And perhaps like programming, it takes a few recipes and a few
| burnt steaks for you "not to worry" about that, you know what's
| good enough eventually. These lists (and algorithms) are never
| completely thorough.
| massysett wrote:
| Good recipes do explain this though. They say heat the oil
| until it shimmers, or until it smokes, or until beads of water
| in the pan sizzle. Or they give an exact temperature, which you
| can read (imperfectly) with an infrared thermometer.
|
| None of these descriptions is perfect, but each is less likely
| to result in a burnt steak.
| andrewflnr wrote:
| By that definition, good recipes are vanishingly rare.
| gizmo686 wrote:
| The difficulty is that the more precise you make your recipe,
| the more you need to account for the specifics of the
| situation; which you cannot possibly know.
|
| There is one time in my life that I recall legit burning a
| steak. I did what I had countless times before. Heated the
| pan until the oil started smoking, put on steak, and reduced
| stove temperature. Just like how I would have written the
| recipe before without a second thought. This time, however,
| the outside was thoroughly burnt before the inside even
| started to cook. The difference was I was using a cast iron
| pan for the first time, which has a lot more thermal mass
| than what I was used to. My old process relief on the steak
| cooling down the pan.
|
| For recipes I'm reading, I've almost always found the
| temperature and time details to be nearly useless. If the
| recipe says to make at 400 F for 30 minutes, I bake on "high"
| (450F) until done. If I'm in someone else's kitchen, my
| cooking turns out a bit worse than when I'm at home.
|
| This is a problem you always run into when writing down a
| process. You need to rely on the knowledge of the person
| following the process to apply it correctly to their specific
| situation. Trying to prescribe every detail does not work
| well.
| marcosdumay wrote:
| "Pre-heat" is done until your apparatus reaches the stable
| cooking temperature. The recipe writer doesn't know your pan
| size, room temperature, stove power, or anything like that, so
| they can't tell you the details.
|
| "Low-medium" is just bad instructions. The recipe should be
| more detailed.
|
| Anyway, what you are complaining about on your example is just
| jargon ignorance. You need to learn some stuff before you
| understand recipes. That's not really what makes programming
| hard. But it does make learning new things hard.
| squeedles wrote:
| That's one of the reasons I loved Ansible from the moment I saw
| it. As the OP points out, traditionally machines accumulated ad-
| hoc changes over a long period of time. Describing the "known
| good" state and running this "checklist" to make sure it is in
| that state both documents the checklist and evaluates it.
|
| Same reason we haven't typed "cc" on the command line to call the
| C compiler on individual files for about 30 years or more.
| kragen wrote:
| The last time I typed (well, pasted) "cc" on the command line
| to call the C compiler on an individual file was 26 hours ago.
| I wanted to recompile a single-file program I'd just written
| with debugging information (-g) and it seemed easier to copy,
| paste, and edit the command line rather than to manually delete
| the file and reinvoke make with different CFLAGS.
|
| I mean, I've surely compiled orders of magnitude more C files
| _without_ typing "cc" on the command line over the last week.
| But it's actually pretty common for me to tweak options like
| -mcpu, -m32, -pg, -Os, or -std=c11 -pedantic (not to mention
| diet cc) by running a "cc" command line directly.
|
| Similarly, I often run Python or JS code in the REPL or in
| Jupyter rather than putting it in a file. The rapid feedback
| sometimes helps me learn things faster. (Other times it's an
| attractive nuisance.)
|
| But I may be a bit of an odd duck. I've designed my own CPU, on
| paper. I write assembly code for fun. I've implemented several
| different programming languages for fun. I like to know what's
| underneath, behind the surface appearances of things. And that
| requires experimenting with it.
| hermitcrab wrote:
| I find checklists invaluable for running my software product
| business.
|
| But any checklist needs to be a living document that has is
| easily updated and under version control.
|
| Personally, I used MyLifeOrganized documents stored in
| Subversion.
| accrual wrote:
| I made a checklist to migrate storage from one host to another
| recently. Like TFA mentions, it ended up being incomplete with
| some key details missing. But I filled in the gaps as I went and
| saved the checklist for next time.
| vorgol wrote:
| Tim Harford mentions in his podcast "Cautionary Tales - A
| Fascination with Failure / Death on the Dance Floor" that
| checklists might have prevented the 1981 skywalk collapse in
| Kansas City Hyatt Regency Hotel (killing 114 people).
|
| It's really a good podcast (pretty much all of his podcasts are)
|
| https://timharford.com/2023/07/cautionary-tales-a-fascinatio...
| cadamsdotcom wrote:
| A checklist can be gradually automated, step-by-step.
|
| Start by automating the low hanging fruit.
|
| After a few iterations you have a somewhat automated process and
| some steps that are harder to automate. Those hard-to-automate
| steps can be annotated with detailed instructions that expose
| opportunities to partly automate them. You can break down each
| step more over time. As you run the checklist, you'll learn &
| iterate. Then with the newly broken down steps, you can automate
| what's become automatable. Repeat forever!
| scubbo wrote:
| Hurrah for do-nothing scripting[0]!
|
| [0] https://blog.danslimmon.com/2019/07/15/do-nothing-
| scripting-...
| azmarks wrote:
| The Checklist Manifesto by Atul Gawande is a must read
| jtrn wrote:
| Indeed. It's actually one of the books that influenced me the
| most. It's squarely in the middle of a Venn diagram of
| psychology, systems thinking, project management, neuroscience,
| healthcare, technology, productivity, and problem solving.
| adolph wrote:
| One of the great thing about that book was how he described
| checklist failure, when best practices checklists from one
| institution didn't generate the same results because the people
| in the receiving institution weren't bought into all the items
| within the checklist and it was just something to click through
| and get done.
| shooker435 wrote:
| Oh man, this was the entire premise of a business I worked on
| years ago: http://manifest.ly/
| regnull wrote:
| I've been fascinated for checklists for a long time, and I've
| been thinking about creating this "checklists on steroids" app,
| where checklists can be shared, created from templates, executed
| (and information about each executing collected), etc.
|
| I finally had some time to spend on it, and here's the result:
| https://checkoff.ai/
|
| Would be grateful for any feedback!
___________________________________________________________________
(page generated 2025-07-23 23:01 UTC)