3 ms·
An employee who dropped production on first day is not at fault, it's the company's fault. I have similar but not quite as bad story, deploying code that almost
by itamarst 9y ago
An employee who dropped production on first day is not at fault, it's the company's fault. I have similar but not quite as bad story, deploying code that almost brought down our company's main customer. My fault, but organization was at fault too (but to be fair we had ops people who shut it off when it caused problems).
So two thoughts:
1. How bad the outcome is doesn't necessarily reflect on how big a mistake something is. Software is so complex that even small hard-to-avoid mistakes can cause big problems... and sometimes big mistakes only cause trivial problems. So while big mistakes make good stories (and I'm sure people will post some), every mistake is worth learning from.
2. Most problems are, in the end, not an individual's fault. It's a whole system that failed. So don't just like for what you can do better, though that's important. Figure out where the system broke, and how to make the system better.
If you want to more deliberately learn from mistakes, Gary Klein's book "The Power of Intuition" is really useful.
(I am BTW writing a weekly email with mistakes I've made both programming and in my career - the story I mentioned above is the first email you'd get, and I just sent out the 41st, with plenty more mistakes to come. 20+ years of coding and still more mistakes to make! https://softwareclown.com https://softwareclown.com if you're interested.)