[itamarst]

Gary Klein wrote a great book about how to learn from experience, based on research in naturalistic decision making, kinda stuff firefighters and NICU nurses do, but also e.g. design engineers for many decisions (https://www.amazon.com/Power-Intuition-Feelings-Better-Decis...).

His advice for learning from mistakes is basically to look for the cues or patterns you missed that caused your mistake. That way you find the hints that would've helped you catch it in time.

I've been doing this myself, and writing up results in a weekly email (https://codewithoutrules.com/softwareclown/) and it really improves how much I learn from mistakes. As in, I go from "well that was stupid of me" to "ohhhhh, I should've noticed that."

Example: early in career I submitted code with bad variable names (foo, bar) to customer who requested I write a library. She pointed that out as bad practice, I was super embarrassed over my bad code. My takeaway in one of initial emails was obvious one of "write readable code."

But later I revisited using the cues/patterns approach, and realized deeper mistake was not listening to what she wanted—in this case, source code. If deliverable wasn't source code then variable names wouldn't have mattered and it would've been fine.

[hutzlibu]

"write readable code."

I think it doesn't matter if you give the source code or not, but you should allways "write readable code".

Sure there is a difference between throw away code and a library, but also for youself it is a good habit to understand later, what you have been doing. And so much more for other people ...

[itamarst]

So, on the one hand, yes definitely.

On the other hand, it's worth digging deeper.

A lot of programming advice is these rules of thumb, and they're mostly good, but they're motivated by underlying principles (which you explain in this particular case). So it's useful to not just have these rules of thumbs, but also to dig deeper and look for underlying motivations.