5 ms·

Checklists are hard, but still a good thing

171 points by zdw 1y ago

devenson 1y ago
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 1y ago
  Would't any additional item increase safety?
  - ceejayoz 1y ago
    No, not if you overdo it. You start getting into https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue territory.
  - 0x457 1y ago
    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 1y ago
  Clearly you need a checklist for making checklists.
- massysett 1y ago
  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 1y ago
  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 1y ago
    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 1y ago
    "Update checklist if needed" should be the last thing on every checklist!
- vorgol 1y ago
  That's just like saying that if no tests are failing then we don't have any bugs.
dvt 1y ago
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 1y ago
  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.
  - davchana 1y ago
    I often use a checklist version for travel packing, where every item simply goes after each other with a checkbox, instead of usual checklist with every new item going on new line.
  - parpfish 1y ago
    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
rapfaria 1y ago
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 1y ago
  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 1y ago
    By that definition, good recipes are vanishingly rare.
  - gizmo686 1y ago
    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.
squeedles 1y ago
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 1y ago
  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.
  - squeedles 1y ago
    Of course I cc one file quickie programs all the time. What I am talking about is a whole directory of source files, and just "knowing" which ones are out of date and building the object files manually. I still remember years ago trying to convince one dev to use make on a package with 20-30 source files.
    - kragen 1y ago
      Running just cc instead of make is actually a much more reasonable thing to do nowadays than it was 10, 20, or 30 years ago. https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-shell.c https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-s... is the entry point to a terminal emulator I wrote, for example. `make -j 8` can build it with GCC from a `make clean` state in 380ms, but if I, for example, `touch admu-shell.c` after a build and run `make -j 8` to run an incremental build, it recompiles and relinks just that one file, which takes 200–250ms. So the incrementality of the build is saving me 230ms–280ms in that case. Without -j, a nonincremental `make admu-shell` takes about 1100ms. But if I instead run time cc -Wall -Wno-cpp -g -Os -I. -std=gnu99 \ admu-shell.c admu.c yeso-xlib.c yeso-pic.c \ png.c jpeg.c ppmp6-read.c readfont.c ypathsea.c \ -lX11 -lXext -lpng -ljpeg -lm -lbsd -lz \ -o admu-shell it takes 900 milliseconds to compile those 1100 lines of C. This is a little bit faster than building from scratch without -j because I'm not compiling the .c files that go into libyeso-xlib.a that admu-shell doesn't use. So all the work of `make` figuring out which ones are out of date and building the object files automatically and in parallel across multiple cores has saved me a grand total of 600–700 milliseconds. That's something, to be sure; it's a saving† that makes the compilation feel immediate. But it's really pretty minor. 900ms is small enough that it only affects my development experience slightly. If I were to run the build in the background as I was editing, I wouldn't be able to tell if it were incremental or from-scratch. Unless it screwed up, that is, for example because I didn't bother to set up makedepends, so if I edit a header file or upgrade a system library I might have to do a scratch build anyway. The `make` incremental-build savings doesn't come without a cost, so we have to question whether that cost is worth the benefit. (In this case I think it's worthwhile to use separate source files and `make` for other reasons: most of that source code is used in multiple Yeso programs, and `make -j` also makes a full build from scratch four or five times faster.) If we extrapolate that 700ms saving backward to 25 years ago when our computers ran 500 million instructions per second instead of 30 billion, it's something like 45 seconds, which is enough of a wait to be distracting and maybe make me lose my train of thought. And 5 years further back, it would have taken several minutes. So `make` was an obvious win even for small projects like this at the time, and an absolute necessity for larger ones. At the time, I was the build engineer on a largish C++ project which in practice took me a week to build, because the build system was kind of broken, and I had to poke at it to fix the problems whenever something got miscompiled. The compiler and linker were writing their output files to an NFS server over shared 10-megabit Ethernet. As another data point, I just rebuilt the tcl8.6-8.6.13+dfsg Debian package. It took 1m24.514s. Recompiling just generic/tclIO.c (5314 SLOC) takes 1.7 seconds. So not doing a full rebuild of the Tcl library can save you a minute and a half, but 25 years ago (when Tcl 8 already existed) that would have been an hour and a half. If it's the late afternoon, you might as well go home for the day, or swordfight somebody in the hallway or something. So incremental builds at the time were totally essential. Now they're a dispensable optimization that isn't always worth it. ______ † 1200 lines of C per second is pretty slow, so probably almost all of that is repeatedly lexing the system header files. I'm guessing that if I took the time to do a "unity build" by concatenating all the C files and consolidating the #includes, I could get that time down to basically the same as the incremental build.
hermitcrab 1y ago
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.
- naiquevin 1y ago
  Same here. I use checklists heavily for my projects. I write them in (emacs) org mode in a way that I can “execute” them repeatedly. Have written about it: https://www.naiquev.in/recurring-checklists-using-org-mode-in-emacs.html https://www.naiquev.in/recurring-checklists-using-org-mode-i...
accrual 1y ago
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 1y ago
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-fascination-with-failure-death-on-the-dance-floor-classic/ https://timharford.com/2023/07/cautionary-tales-a-fascinatio...
cadamsdotcom 1y ago
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 1y ago
  Hurrah for do-nothing scripting[0]! [0] https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...
azmarks 1y ago
The Checklist Manifesto by Atul Gawande is a must read
- jtrn 1y ago
  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 1y ago
  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 1y ago
Oh man, this was the entire premise of a business I worked on years ago: http://manifest.ly/ http://manifest.ly/
regnull 1y ago
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/ https://checkoff.ai/ Would be grateful for any feedback!
gleb 1y ago
Checklists are extremely hard. Writing them requires the skill of the programmer and direct response copywriter, and few people have both. Ensuring that people actually use the checklists is brutally difficult. And creating systems to improve the checklists as they are used is even harder. I suspect checklists being so hard is the reason they're so rarely used.
GuB-42 1y ago
I have be wondering about do-not-check lists to go with checklists. I am mostly thinking about packing list, as it is common to overpack when travelling, so it can be good to have a list of things you think will be useful but are not. For example, if you are travelling in hotels (as opposed to hitchhiking ;)), you probably don't need a towel, because they are usually provided, so, to the do-not-pack list. The problem with checklist, especially the ones that change over time is that they sometimes go out of control with useless items, a do-not-check list means "I removed this from the checklist, there is a good reason, don't put it back"
susiecambria 1y ago
I learned about checklists (versus to do lists) from Dr. Atul Gawande. He has done a great deal of work on checklists in medicine because of the complexity in the field and as a way to force/facilitate communication. He wrote The Checklist Manifesto - How to Get Things Right, has been interviewed a gazillion times about the need for the surgical checklist, and talks extensively about the challenges associated with getting hospitals and medical practices to adopt the surgical checklist. NPR's Atul Gawande's Checklist For Surgery Success [1] is a short version of the problem, challenges, inspiration, and solution. And more recently, look forward to Captain Steeeve [2] talking about checklists pilots use. [1] https://www.npr.org/2010/01/05/122226184/atul-gawandes-checklist-for-surgery-success https://www.npr.org/2010/01/05/122226184/atul-gawandes-check... [2] https://www.youtube.com/@CaptainSteeeve https://www.youtube.com/@CaptainSteeeve
ww520 1y ago
When business approach me asking for automating a business process, I usually ask them to do the process in manual steps and create check lists for it. The check lists force them to think it through and are the agreed upon steps to perform the process. After they do it by hand for a while and find out where the pain points are, we can then automate. Since the check lists are already in place, automation is really easy.
blakehaswell 1y ago
One thing that might not be obvious about checklists is how they're used. I used to think checklists were used by reading the item, then doing the thing. I literally thought of them as a recipe that you would follow. Complete a step, check the box, repeat... This is typically referred to as a "read, do" checklist. In aviation this style of checklist is typically reserved for non-normal operations—procedures that you wouldn't use often enough to commit to memory. The other style of checklist is "do, confirm". In this style you complete a procedure by memory, and read through a checklist to ensure you didn't miss anything (no box ticking, you just read the items and confirm to yourself that they're complete). In aviation this is the style used for normal operations, and for the initial action-items in an emergency (which although not commonly used, must be committed to memory because they are time-critical). Because you're expecting that the procedure is completed by memory, a "do, confirm" checklist can be extremely brief. You do not need to write in detail what each step involves, you just need a word or two to name the step. Additionally, they're an extremely low operational burden; it takes a couple of seconds to read through a "do, confirm" checklist but the upside of catching common errors is significant.
wcfrobert 1y ago
I love that Eisenhower quote which I feel is quite relevant here. "plans are useless, planning is essential."
kqr 1y ago
Many people in this discussion seem to confuse checklists with to do lists. A checklist is an established, recurring procedure that is ideally memorised, but despite that one goes through each item on the checklist to make sure nothing is forgotten or performed out of sequence or twice. A to do list is an ad hoc collection of tasks that need to be performed. The list is built for each occasion rather than covering a standard procedure.
ChrisMarshallNY 1y ago
The company that I used to work for, used huge checklists (sometimes, thousands of items). Of course, these checklists manifested as Excel spreadsheets.
- danparsonson 1y ago
  Wow, doing what?
  - ChrisMarshallNY 1y ago
    Japanese manufacturing company. Checklists are very popular in Japan, as is Excel.
zhaohan_dong 1y ago
I use checklist as a pilot, but trying to introduce the same habit to software engineers are hard. The cost of reversing a decision is cheaper in software, than to say flying or doing hardware. Plus the spec requirements for flying and hardware design rarely changes as often as software. Still swear by checklists and SOPs but have to be at peace that others don't see it the same way.
0xCE0 1y ago
Checklists are one of the most powerful universal tool I know for avoiding/minimizing disasters/failures. In the context of software, I try to create user interfaces as masked checklists, because it forces making critical steps/decisions visible and clear (common domain specific understanding for both developer and end user), and guides user to goal. It's almost like old-school "wizard" UIs, but professionals in mind instead of beginners. Also, critical business processes are great expressed as checklists.

171 points by zdw 1y ago

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 1y ago
Would't any additional item increase safety?
- ceejayoz 1y ago
  No, not if you overdo it. You start getting into https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue territory.
- 0x457 1y ago
  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 1y ago
Clearly you need a checklist for making checklists.
massysett 1y ago
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 1y ago
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 1y ago
  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 1y ago
  "Update checklist if needed" should be the last thing on every checklist!
vorgol 1y ago
That's just like saying that if no tests are failing then we don't have any bugs.

dvt 1y ago

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 1y ago
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.
- davchana 1y ago
  I often use a checklist version for travel packing, where every item simply goes after each other with a checkbox, instead of usual checklist with every new item going on new line.
- parpfish 1y ago
  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

rapfaria 1y ago

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 1y ago
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 1y ago
  By that definition, good recipes are vanishingly rare.
- gizmo686 1y ago
  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.

squeedles 1y ago

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 1y ago
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.
- squeedles 1y ago
  Of course I cc one file quickie programs all the time. What I am talking about is a whole directory of source files, and just "knowing" which ones are out of date and building the object files manually. I still remember years ago trying to convince one dev to use make on a package with 20-30 source files.
  - kragen 1y ago
    Running just cc instead of make is actually a much more reasonable thing to do nowadays than it was 10, 20, or 30 years ago. https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-shell.c https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-s... is the entry point to a terminal emulator I wrote, for example. `make -j 8` can build it with GCC from a `make clean` state in 380ms, but if I, for example, `touch admu-shell.c` after a build and run `make -j 8` to run an incremental build, it recompiles and relinks just that one file, which takes 200–250ms. So the incrementality of the build is saving me 230ms–280ms in that case. Without -j, a nonincremental `make admu-shell` takes about 1100ms. But if I instead run time cc -Wall -Wno-cpp -g -Os -I. -std=gnu99 \ admu-shell.c admu.c yeso-xlib.c yeso-pic.c \ png.c jpeg.c ppmp6-read.c readfont.c ypathsea.c \ -lX11 -lXext -lpng -ljpeg -lm -lbsd -lz \ -o admu-shell it takes 900 milliseconds to compile those 1100 lines of C. This is a little bit faster than building from scratch without -j because I'm not compiling the .c files that go into libyeso-xlib.a that admu-shell doesn't use. So all the work of `make` figuring out which ones are out of date and building the object files automatically and in parallel across multiple cores has saved me a grand total of 600–700 milliseconds. That's something, to be sure; it's a saving† that makes the compilation feel immediate. But it's really pretty minor. 900ms is small enough that it only affects my development experience slightly. If I were to run the build in the background as I was editing, I wouldn't be able to tell if it were incremental or from-scratch. Unless it screwed up, that is, for example because I didn't bother to set up makedepends, so if I edit a header file or upgrade a system library I might have to do a scratch build anyway. The `make` incremental-build savings doesn't come without a cost, so we have to question whether that cost is worth the benefit. (In this case I think it's worthwhile to use separate source files and `make` for other reasons: most of that source code is used in multiple Yeso programs, and `make -j` also makes a full build from scratch four or five times faster.) If we extrapolate that 700ms saving backward to 25 years ago when our computers ran 500 million instructions per second instead of 30 billion, it's something like 45 seconds, which is enough of a wait to be distracting and maybe make me lose my train of thought. And 5 years further back, it would have taken several minutes. So `make` was an obvious win even for small projects like this at the time, and an absolute necessity for larger ones. At the time, I was the build engineer on a largish C++ project which in practice took me a week to build, because the build system was kind of broken, and I had to poke at it to fix the problems whenever something got miscompiled. The compiler and linker were writing their output files to an NFS server over shared 10-megabit Ethernet. As another data point, I just rebuilt the tcl8.6-8.6.13+dfsg Debian package. It took 1m24.514s. Recompiling just generic/tclIO.c (5314 SLOC) takes 1.7 seconds. So not doing a full rebuild of the Tcl library can save you a minute and a half, but 25 years ago (when Tcl 8 already existed) that would have been an hour and a half. If it's the late afternoon, you might as well go home for the day, or swordfight somebody in the hallway or something. So incremental builds at the time were totally essential. Now they're a dispensable optimization that isn't always worth it. ______ † 1200 lines of C per second is pretty slow, so probably almost all of that is repeatedly lexing the system header files. I'm guessing that if I took the time to do a "unity build" by concatenating all the C files and consolidating the #includes, I could get that time down to basically the same as the incremental build.

hermitcrab 1y ago

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.

naiquevin 1y ago
Same here. I use checklists heavily for my projects. I write them in (emacs) org mode in a way that I can “execute” them repeatedly. Have written about it: https://www.naiquev.in/recurring-checklists-using-org-mode-in-emacs.html https://www.naiquev.in/recurring-checklists-using-org-mode-i...

accrual 1y ago

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 1y ago

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-fascination-with-failure-death-on-the-dance-floor-classic/ https://timharford.com/2023/07/cautionary-tales-a-fascinatio...

cadamsdotcom 1y ago

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 1y ago
Hurrah for do-nothing scripting[0]! [0] https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...

azmarks 1y ago

The Checklist Manifesto by Atul Gawande is a must read

jtrn 1y ago
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 1y ago
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 1y ago

Oh man, this was the entire premise of a business I worked on years ago: http://manifest.ly/ http://manifest.ly/

regnull 1y ago

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/ https://checkoff.ai/ Would be grateful for any feedback!

gleb 1y ago

Checklists are extremely hard. Writing them requires the skill of the programmer and direct response copywriter, and few people have both. Ensuring that people actually use the checklists is brutally difficult. And creating systems to improve the checklists as they are used is even harder. I suspect checklists being so hard is the reason they're so rarely used.

GuB-42 1y ago

I have be wondering about do-not-check lists to go with checklists. I am mostly thinking about packing list, as it is common to overpack when travelling, so it can be good to have a list of things you think will be useful but are not. For example, if you are travelling in hotels (as opposed to hitchhiking ;)), you probably don't need a towel, because they are usually provided, so, to the do-not-pack list. The problem with checklist, especially the ones that change over time is that they sometimes go out of control with useless items, a do-not-check list means "I removed this from the checklist, there is a good reason, don't put it back"

susiecambria 1y ago

I learned about checklists (versus to do lists) from Dr. Atul Gawande. He has done a great deal of work on checklists in medicine because of the complexity in the field and as a way to force/facilitate communication. He wrote The Checklist Manifesto - How to Get Things Right, has been interviewed a gazillion times about the need for the surgical checklist, and talks extensively about the challenges associated with getting hospitals and medical practices to adopt the surgical checklist. NPR's Atul Gawande's Checklist For Surgery Success [1] is a short version of the problem, challenges, inspiration, and solution. And more recently, look forward to Captain Steeeve [2] talking about checklists pilots use. [1] https://www.npr.org/2010/01/05/122226184/atul-gawandes-checklist-for-surgery-success https://www.npr.org/2010/01/05/122226184/atul-gawandes-check... [2] https://www.youtube.com/@CaptainSteeeve https://www.youtube.com/@CaptainSteeeve

ww520 1y ago

When business approach me asking for automating a business process, I usually ask them to do the process in manual steps and create check lists for it. The check lists force them to think it through and are the agreed upon steps to perform the process. After they do it by hand for a while and find out where the pain points are, we can then automate. Since the check lists are already in place, automation is really easy.

blakehaswell 1y ago

One thing that might not be obvious about checklists is how they're used. I used to think checklists were used by reading the item, then doing the thing. I literally thought of them as a recipe that you would follow. Complete a step, check the box, repeat... This is typically referred to as a "read, do" checklist. In aviation this style of checklist is typically reserved for non-normal operations—procedures that you wouldn't use often enough to commit to memory. The other style of checklist is "do, confirm". In this style you complete a procedure by memory, and read through a checklist to ensure you didn't miss anything (no box ticking, you just read the items and confirm to yourself that they're complete). In aviation this is the style used for normal operations, and for the initial action-items in an emergency (which although not commonly used, must be committed to memory because they are time-critical). Because you're expecting that the procedure is completed by memory, a "do, confirm" checklist can be extremely brief. You do not need to write in detail what each step involves, you just need a word or two to name the step. Additionally, they're an extremely low operational burden; it takes a couple of seconds to read through a "do, confirm" checklist but the upside of catching common errors is significant.

wcfrobert 1y ago

I love that Eisenhower quote which I feel is quite relevant here. "plans are useless, planning is essential."

kqr 1y ago

Many people in this discussion seem to confuse checklists with to do lists. A checklist is an established, recurring procedure that is ideally memorised, but despite that one goes through each item on the checklist to make sure nothing is forgotten or performed out of sequence or twice. A to do list is an ad hoc collection of tasks that need to be performed. The list is built for each occasion rather than covering a standard procedure.

ChrisMarshallNY 1y ago

The company that I used to work for, used huge checklists (sometimes, thousands of items). Of course, these checklists manifested as Excel spreadsheets.

danparsonson 1y ago
Wow, doing what?
- ChrisMarshallNY 1y ago
  Japanese manufacturing company. Checklists are very popular in Japan, as is Excel.

zhaohan_dong 1y ago

I use checklist as a pilot, but trying to introduce the same habit to software engineers are hard. The cost of reversing a decision is cheaper in software, than to say flying or doing hardware. Plus the spec requirements for flying and hardware design rarely changes as often as software. Still swear by checklists and SOPs but have to be at peace that others don't see it the same way.

0xCE0 1y ago

Checklists are one of the most powerful universal tool I know for avoiding/minimizing disasters/failures. In the context of software, I try to create user interfaces as masked checklists, because it forces making critical steps/decisions visible and clear (common domain specific understanding for both developer and end user), and guides user to goal. It's almost like old-school "wizard" UIs, but professionals in mind instead of beginners. Also, critical business processes are great expressed as checklists.