Comment by drewcoo | Hacker News Reader

Comment by drewcoo | Hacker News Reader

Why is this here?

Is it because "down to the actual commands I was going to carry out,"

meaning a process that wasn't automatable?

Is it because "committed a couple of small mis-steps . . ." whoops! Lesson learned?

I don't believe this: "While I understand why I made these mis-steps, I'm also going to try to improve our environment so that people following my approach to writing up a checklist can't make them in the future."

Because everything else seems to be a one-off. So this lesson is, too. And if all the other one-off lessons aren't quite learned, what is the effect of adding one more? It seems unlikely to succeed.

"Doing this successfully requires me to remember and understand . . ." and that is exactly why that fails. Doing something successfully should be so simple that anyone can do it. The biggest idiot you know can do it without fail. Because you are an engineer and you design simple solutions for complicated problems. Such simple solutions that a complete idiot (or a middle manager) can grok them and succeed.

That, friend, is professional ethics in our field.

(P.S. Checklists are wonderful. Ask anyone who's flown in a plane or had surgery lately.)

Please be kind, even when your gut reaction is: this is crap. You probably have valuable knowledge to bring a discussion on ‘How to learn from your mistakes and prevent them in the future’ to a higher level. Can you share how you automate repeating tasks, how you combine this with checklists and what kind of process you would advise for learning from things that went wrong?

Reading the linked blog post and a bit of the other stuff there I echo the frustration of the parent. Give me a bash script, not a checklist. They're requiring more attention from the user than is appropriate.

Let's not restrict ourselves to only "kindness". Kind is how you act with a baby. Our profession needs truthful authentic expression.

As someone who probably has dyspraxia(One of those ADHD/Dyslexia/etc type conditions), I often just stop listening when someones idea of a solution involves learning something or doing something different next time..

Remembering and understanding are far too intangible to be part of a technical plan.

"Being careful" is essentially non-actionable or at best a crappy shorthand for working slowly and avoiding distractions, which is not always possible.

Crew Resources Management(Everyone needs to study this) understands that mistakes aren't just a lack of training. They are sometimes "Human error" coming from the fact that people are just not 100% reliable.

Everyone likes to act like you can just train more and get to 100%, and you should just accept the consequences when you don't, but that seems like a fancy way of saying "My natural reliability is better than yours, and I want all these lesser people out of my industry and preferably in a group home".

You may me 10x more skilled than me , but if I delete the wrong file, I just restore it from the trash. If you delete the wrong file, it's gone, because you trusted in your own ability rather than the computer, and used rm instead of a GUI.

A lot of environments aren't amenable to scripting (i.e. involved GUI tools, or multiple disconnected systems), and a lot of processes need manual monitoring steps or multiple fallback contingencies that are hard to codify into a machine-executable script.

There may also be security processes (server resides in a hardened facility and someone with clearance needs to physically walk into the SCIF to initiate), or business processes (exec+comms+legal teams need to sign-off on the exact launch timing for a signature feature) that are tangled up in your checklist.

Reply on news.ycombinator.com