7 ms·

Document your mistakes and then try to block them in the future

86 points by zdw 5y ago

sbmthakur 5y ago
Started doing this after reading an article on the same topic by Aaron Swartz[0]. I write the mistakes in Obsidian and link them with other things in my life. 0. http://www.aaronsw.com/weblog/geremiah http://www.aaronsw.com/weblog/geremiah
drewcoo 5y ago
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.)
- defenestration 5y ago
  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?
  - janto 5y ago
    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.
- swiftcoder 5y ago
  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.
- eternityforest 5y ago
  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.
KingOfCoders 5y ago
Everyone of my projects now has a LEARNINGS.txt file.
- LilBytes 5y ago
  Or a #Pain, #Headaches or #WTF header in the readme.md for me.
29athrowaway 5y ago
One day I sat down and instead of a todo list, I wrote a "stop doing" list. It was a useful exercise.
- eternityforest 5y ago
  A todon't list!
  - 29athrowaway 5y ago
    I titled it "nodo"
mkl95 5y ago
Whenever I'm learning something, every non trivial action or step becomes an org-mode top level headline * It's a pretty effective way of solving problems asynchronously - you can go back to whatever you were attempting a while ago, and all the boilerplate and relevant details will be conveniently documented in a tiny file. * https://orgmode.org/manual/Headlines.html https://orgmode.org/manual/Headlines.html
PradeetPatel 5y ago
Friendly reminder that it's recommended to document it in an encrypted file in the event that your mistakes may have regulatory, compliance, or legal consequences. An advice from a mentor of mine when I first started my journey in reputation management, plausible deniability has saved me and my clients on numerous occasions.
- jka 5y ago
  Without mentioning any of the incidents involved, could you link to one of the rules mentioned that discouraged documentation of technical mistakes? (my guess is that those may have been written at a point in time during which it did make sense to prevent publication/knowledge of mistakes like that - I'm wondering whether that remains a good policy nowadays, when risk-reduction can often benefit from information-sharing, even around failures and errors)
- Havoc 5y ago
  > regulatory, compliance, or legal consequences. Encryption won't save you from any of that. >plausible deniability has saved me and my clients on numerous occasions. right...OK maybe it will if that's how it is employed. Quite risky though. Encrypting stuff & "forgetting" the password versus say shredding evidence isn't that far apart.
  - gruez 5y ago
    > right...OK maybe it will if that's how it is employed. Quite risky though. Encrypting stuff & "forgetting" the password versus say shredding evidence isn't that far apart. Disagree. Shredding evidence is an active action that can be used to establish guilt. Forgetting a password requires none of that.
  - BeFlatXIII 5y ago
    Shredding a pile of evidence is legally actionable. Shredding any documents left laying about after one week every week is a standard security process.
- spaetzleesser 5y ago
nudpiedo 5y ago
That's useful, it is a way to cristalize experience. Experience comes at a high cost, learning through experimentation, and extracting lessons seems a good way. However the day the environment and circumstances change, past experience might become obsolete, that's when young people have an edge and the fresh blood replaces the old one (that's a society feature, not an individual "bug"). I would totally support a system like that, something in the lines of knowledge database like some companies have (forums and Q&A).
stephendause 5y ago
This is something that I've thought some about doing and sometimes try to do, albeit haphazardly. One thing I've wondered about is whether the overhead of recording your mistakes and then looking them up in the future is worth it. I probably make at least a couple dozen small mistakes a day, depending on my level of familiarity with the tools that I am using. It's been difficult for me to decide what to write down and what not to. On the one hand, I may encounter an issue again, but then again, maybe I'll just remember how it works naturally if I encounter the issue frequently, so it might not be worth the time. As an example, if I am learning git, the subtleties of the `git checkout` command would likely trip me up, but should I write that down? It is such a common command that, if I am using git regularly, I will probably remember it without having to write it down. As another example, what if I have an issue with something that I likely won't ever use again? Say, for example, I have to get my W-2 from a former employer, and their Web site requires you to call a number that's really hard to find to reset your password and then navigate a complicated phone tree. Should I write down the mistakes I made in figuring out how to do all that? I would say probably not, because I won't have to deal with this issue again. Finally, there is the fact that technologies change. Some things, like Unix commands, are pretty stable, whereas other things, like best practices for JavaScript, are not. How much time should I dedicate to writing things down when they are likely to change? All of this is to say: I agree it's a good thing to document mistakes, and I should probably do that more systematically, but I think there is some art to deciding what to write down and what not to.
eternityforest 5y ago
I've done this extensively and have compiled a lot of data because of how many mistakes I make, and am working on this document, an ongoing set of strategies for decoupling success from natural talent: https://github.com/EternityForest/AnyoneCanDoIt https://github.com/EternityForest/AnyoneCanDoIt My most important rules: 1. There is no later. I assume that time is a concept only machines can process. If someone tells me to do something when X happens or check something in an hour or so, I immediately set reminders. I don't even consider trying to just remember as an option, I know my failure rate will be well over 80%. 2. Absolutely no mental rotation. Learn to recognize any thought process that involves a rotation, and assume results are invalid. I check the map after after every turn. I never compare objects in different orientations. 3. The verbal machine gun strategy When someone is trying to get me to do something dangerous, and starts talking fast, I assume it's basically suppressive fire for thought. If I were to explain why it's a bad idea in their pitch and tone I'd sound like a maniac, but they can talk as fast as they want because they are relying on tradition and intuition, not complicated reasoning. "Come on, it will be fun" is easier to say fast then "I literally know a guy who was very experienced, who tried this, and died". The only defense I know of is to not care what they think or how you look, and have nothing to prove, especially not to yourself. 4. Never assume any task is too simple and easy to need a plan. If you give me a bucket of balls and ask me to count them, I'm going to pull out a counter app. That 10% of the time I lose count before getting to 10 is embarrassing enough to be worth the trouble to avoid.
- tpoacher 5y ago
  > When someone is trying to get me to do something dangerous, and starts talking fast, I assume it's basically suppressive fire for thought Nice insight!
- arapacana 5y ago
  This is so freaking amazing, and I think the ultimate publication goal of my "daily insights" Notion page. Thank you so much for this, will be a treat to absorb.
- carapace 5y ago
  In re: #1, the brain has pretty precise timing. It's fairly easy to develop the ability to, in effect, set internal timers. Most people who know this only use it for waking up at specific times, but it can work for anything.
jrsj 5y ago
I would do this but every time there’s a problem I’m too busy proving why it isn’t my fault since everyone defaults to blame shifting in those situations. The documentation has to be focused on what mistakes other people made & what mistakes you didn’t make. Or at least it’s been the case everywhere I’ve ever worked. I don’t know how anything gets done in this industry with internal politics being what they are. Especially now that we’ve added the DE&I grifters to the mix too.

86 points by zdw 5y ago

Started doing this after reading an article on the same topic by Aaron Swartz[0]. I write the mistakes in Obsidian and link them with other things in my life. 0. http://www.aaronsw.com/weblog/geremiah http://www.aaronsw.com/weblog/geremiah

drewcoo 5y ago

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.)

defenestration 5y ago
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?
- janto 5y ago
  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.
swiftcoder 5y ago
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.
eternityforest 5y ago
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.

KingOfCoders 5y ago

Everyone of my projects now has a LEARNINGS.txt file.

LilBytes 5y ago
Or a #Pain, #Headaches or #WTF header in the readme.md for me.

29athrowaway 5y ago

One day I sat down and instead of a todo list, I wrote a "stop doing" list. It was a useful exercise.

eternityforest 5y ago
A todon't list!
- 29athrowaway 5y ago
  I titled it "nodo"

mkl95 5y ago

Whenever I'm learning something, every non trivial action or step becomes an org-mode top level headline * It's a pretty effective way of solving problems asynchronously - you can go back to whatever you were attempting a while ago, and all the boilerplate and relevant details will be conveniently documented in a tiny file. * https://orgmode.org/manual/Headlines.html https://orgmode.org/manual/Headlines.html

PradeetPatel 5y ago

Friendly reminder that it's recommended to document it in an encrypted file in the event that your mistakes may have regulatory, compliance, or legal consequences. An advice from a mentor of mine when I first started my journey in reputation management, plausible deniability has saved me and my clients on numerous occasions.

jka 5y ago
Without mentioning any of the incidents involved, could you link to one of the rules mentioned that discouraged documentation of technical mistakes? (my guess is that those may have been written at a point in time during which it did make sense to prevent publication/knowledge of mistakes like that - I'm wondering whether that remains a good policy nowadays, when risk-reduction can often benefit from information-sharing, even around failures and errors)
Havoc 5y ago
> regulatory, compliance, or legal consequences. Encryption won't save you from any of that. >plausible deniability has saved me and my clients on numerous occasions. right...OK maybe it will if that's how it is employed. Quite risky though. Encrypting stuff & "forgetting" the password versus say shredding evidence isn't that far apart.
- gruez 5y ago
  > right...OK maybe it will if that's how it is employed. Quite risky though. Encrypting stuff & "forgetting" the password versus say shredding evidence isn't that far apart. Disagree. Shredding evidence is an active action that can be used to establish guilt. Forgetting a password requires none of that.
- BeFlatXIII 5y ago
  Shredding a pile of evidence is legally actionable. Shredding any documents left laying about after one week every week is a standard security process.
spaetzleesser 5y ago

nudpiedo 5y ago

That's useful, it is a way to cristalize experience. Experience comes at a high cost, learning through experimentation, and extracting lessons seems a good way. However the day the environment and circumstances change, past experience might become obsolete, that's when young people have an edge and the fresh blood replaces the old one (that's a society feature, not an individual "bug"). I would totally support a system like that, something in the lines of knowledge database like some companies have (forums and Q&A).

stephendause 5y ago

This is something that I've thought some about doing and sometimes try to do, albeit haphazardly. One thing I've wondered about is whether the overhead of recording your mistakes and then looking them up in the future is worth it. I probably make at least a couple dozen small mistakes a day, depending on my level of familiarity with the tools that I am using. It's been difficult for me to decide what to write down and what not to. On the one hand, I may encounter an issue again, but then again, maybe I'll just remember how it works naturally if I encounter the issue frequently, so it might not be worth the time. As an example, if I am learning git, the subtleties of the `git checkout` command would likely trip me up, but should I write that down? It is such a common command that, if I am using git regularly, I will probably remember it without having to write it down. As another example, what if I have an issue with something that I likely won't ever use again? Say, for example, I have to get my W-2 from a former employer, and their Web site requires you to call a number that's really hard to find to reset your password and then navigate a complicated phone tree. Should I write down the mistakes I made in figuring out how to do all that? I would say probably not, because I won't have to deal with this issue again. Finally, there is the fact that technologies change. Some things, like Unix commands, are pretty stable, whereas other things, like best practices for JavaScript, are not. How much time should I dedicate to writing things down when they are likely to change? All of this is to say: I agree it's a good thing to document mistakes, and I should probably do that more systematically, but I think there is some art to deciding what to write down and what not to.

eternityforest 5y ago

I've done this extensively and have compiled a lot of data because of how many mistakes I make, and am working on this document, an ongoing set of strategies for decoupling success from natural talent: https://github.com/EternityForest/AnyoneCanDoIt https://github.com/EternityForest/AnyoneCanDoIt My most important rules: 1. There is no later. I assume that time is a concept only machines can process. If someone tells me to do something when X happens or check something in an hour or so, I immediately set reminders. I don't even consider trying to just remember as an option, I know my failure rate will be well over 80%. 2. Absolutely no mental rotation. Learn to recognize any thought process that involves a rotation, and assume results are invalid. I check the map after after every turn. I never compare objects in different orientations. 3. The verbal machine gun strategy When someone is trying to get me to do something dangerous, and starts talking fast, I assume it's basically suppressive fire for thought. If I were to explain why it's a bad idea in their pitch and tone I'd sound like a maniac, but they can talk as fast as they want because they are relying on tradition and intuition, not complicated reasoning. "Come on, it will be fun" is easier to say fast then "I literally know a guy who was very experienced, who tried this, and died". The only defense I know of is to not care what they think or how you look, and have nothing to prove, especially not to yourself. 4. Never assume any task is too simple and easy to need a plan. If you give me a bucket of balls and ask me to count them, I'm going to pull out a counter app. That 10% of the time I lose count before getting to 10 is embarrassing enough to be worth the trouble to avoid.

tpoacher 5y ago
> When someone is trying to get me to do something dangerous, and starts talking fast, I assume it's basically suppressive fire for thought Nice insight!
arapacana 5y ago
This is so freaking amazing, and I think the ultimate publication goal of my "daily insights" Notion page. Thank you so much for this, will be a treat to absorb.
carapace 5y ago
In re: #1, the brain has pretty precise timing. It's fairly easy to develop the ability to, in effect, set internal timers. Most people who know this only use it for waking up at specific times, but it can work for anything.

jrsj 5y ago

I would do this but every time there’s a problem I’m too busy proving why it isn’t my fault since everyone defaults to blame shifting in those situations. The documentation has to be focused on what mistakes other people made & what mistakes you didn’t make. Or at least it’s been the case everywhere I’ve ever worked. I don’t know how anything gets done in this industry with internal politics being what they are. Especially now that we’ve added the DE&I grifters to the mix too.