35 comments

[ 1.2 ms ] story [ 85.0 ms ] thread
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.

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.

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.

Everyone of my projects now has a LEARNINGS.txt file.
Or a #Pain, #Headaches or #WTF header in the readme.md for me.
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

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.

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)

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

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

Shredding a pile of evidence is legally actionable. Shredding any documents left laying about after one week every week is a standard security process.
I work in a regulated industry and I try to keep all problems as open and widely known as possible. There are others who like to keep everything secret which has led to known problems not being fixed for a long time.

I am just a small engineer but this strategy seems to have worked in my small area. We are finally following industry standards, pentesting gets done (some people still resist though. They think it's better not to know about problems) and in general things don't get ignored anymore.

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

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.

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

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.

> 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!

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.
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.
I think that pretty heavily depends on natural level of ability. Is there some kind of special training program people use? I've never really heard anyone describe it, and the ones who can seem to not have done anything special to learn

Is it some kind of polling strategy where people somehow get in the habit of asking "What am I forgetting" every few seconds while also doing other things?

It seems like more of a thing that just happens, like the correct thought "I need to check the pot on the stove" just comes from nowhere at the right time, without any external stimulus or process that you can learn from a book.

Just thinking about the thing all day definitely doesn't seem to help, as soon as you stop thinking about it, it's gone till something reminds you if you don't have this mysterious power.

> I think that pretty heavily depends on natural level of ability.

I saw that you say in another comment that you think you probably have dyspraxia, so maybe there's something organic that prevents you from doing this. I'm no expert! But I would encourage you to experiment before you rule it out, eh?

I should point out that I don't have any information about the prevalence of this ability, just that (some) people have known about it for a fairly long time (1000's of years?) and it's not uncommon.

> Is there some kind of special training program people use?

Some people have a little "ritual" of tapping their head on their pillow N times where N is the hour at which they wish to awaken. E.g. six times to wake up at six AM. That's nice and all, but you can get a resolution of a minute or two. (I mean that you can "set a reminder" for, say, 6:38 AM and you'll wake up at 6:37 AM.)

> I've never really heard anyone describe it, ...

It's one of those things that "everybody knows" and yet "no one knows", y'know? Like how some people can seal their nostrils against water voluntarily, or curl their tongues in unpsidedown taco shape.

Here's a random article I found from a quick search "head tap to wake up" on DDG (second result): https://www.personal-development-planet.com/Internal-Alarm.h...

https://www.personal-development-planet.com/Internal-Alarm.h...

> ...and the ones who can seem to not have done anything special to learn

Yeah, it's intrinsic. You don't have to learn anything special to do this. The article linked above mentions "a study by Jan Born at the University of Lubeck in Germany, which found that our body knows when it is due to wake up and starts releasing “wake up” chemicals a full 90 minutes before the scheduled wake-up". So you're already doing it, just not deliberately.

> Is it some kind of polling strategy ...

Goodness no! That would be so inconvenient. It works like an interrupt, to use computer metaphor.

> the correct thought "I need to check the pot on the stove" just comes from nowhere at the right time, without any external stimulus or process that you can learn from a book.

Exactly. One minute you're, say, typing a comment on HN, and the next moment you just "know" it's time to get the laundry out of the dryer. So you stop, grab the basket, and go to the dryer, and reach it just as it stops.

From your link:

> Use Bluetooth headphones instead of corded ones.

My dislike of this sentence is so potent it could fuel a lifelong plan to do the opposite of all your points just to spite the list that gave birth to it.

In more practical terms, the fact that I did not fudge around with Bluetooth headphone problems in the last year alone probably saved me enough time to enjoy a peaceful, tasty dinner at a fine dining establishment.

Really? What phone OS are you on?

On new Androids BT is wonderful, all the switching is in the tray menu. Turn on headphones, it connects, turn them off or use the switch to go back.

I also don't ever turn Bluetooth off though, or even have the button to do so in my quick shortcuts, so things might be different if I did.

And I do remember older androids being annoying, since you couldn't switch away from the headphones in a hurry without turning it off.

But as is, I'm pretty much pro-3.5mmless and don't think I'd ever want to go back to cords.

Not the parent comment, but I have had a devil of a time getting Bluetooth headphones to work with Ubuntu. By contrast, my experience with Android has been the same as yours -- basically flawless, and I love it.
Sharing a Bluetooth between multiple devices does seem to be a weak point of the protocol, that only works when the device explicitly supports it like Logitech's fantastic mice.

I expect PipeWire is going to fix this for the most part though.

I haven't really used BT much on desktop in general though, I have a Fire stick for videos and phones are perfectly fine for music.

Bluetooth hell is far worse than any dependency hell I have ever seen.

I wouldn't wish that on my worst enemy.

Bluetooth audio is just about the worst possible audio that could possibly exist and still survive. The proprietary 2.4ghz wireless audio formats from Logitech and HyperX are proof that wireless audio can work, and work well. Bluetooth exists as the counter example of how bad an audio format can be, and somehow still survive.

I think I've wasted mote time on the last 2 years fudging around bad contacts on wired phones than around bluetooth ones. But I only ever use them on some kind of Linux, where I avoid the bullshit of the "this phone is not allowed to plug into this application" kind (I don't know about Macs). And Android is getting close enough to it that I've seen related problems (on Microsoft applications, obviously).
Nice list! I will have to read and think about it more, but I definitely agree with the spirit of it. You may like the book Atomic Habits. It has many suggestions that are similar to yours, although it approaches self-improvement from the angle of forming and maintaining healthy and productive habits.

https://www.goodreads.com/book/show/40121378-atomic-habits

I like to try to figure out what I did wrong, and then figure out what positive things I could have done that would have avoided the problem. Then focus on continuing to practice those positive things that will hopefully help me avoid such problems again in the future.

The key here is that there are an infinite number of infinite things that you do not want to have happen, and at any point in time there are a finite number of positive things you do want to have happen. If you waste all your energy focusing on the negative things you do not want, then you will never have any energy to focus on the positive things you do want.

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.