This is probably going to come across rude, but I feel like it needs to be said.
nothing in your post was really relevant to this discussion. The fact that it may have been a company policy or that the person wasn't a developer is completely irrelevant to the larger idea. It's literally missing the forest for the trees.
I've been doing software dev for over 20 years and one of the things I'm known for is building very stable systems. Part of the way I do this is by not allowing myself to use these sorts of things as a defense.
When designing and/or building a system I ask: What should not be? Then I build the system to actively look for those situations. Put another way, I don't build systems with the assumption that there are no bugs. Too many developers push the responsibility outside of themselves. As if bugs are inevitable, therefore the fallout from bugs is inevitable. You just do a root cause analysis and move on rather than asking what you could have done differently to avoid the fallout.
I've lost count of the number of times systems I've built have actively refused to do something and then sent out a notification explaining why.
My point here is that you're doing yourself a disservice by insisting that root cause analysis should be enough. Yes it's important, but it's not enough. Some things simply should not be, and they're avoidable.
The problem is that many companies don't really care.
I don't think it's rude to point out someone is missing the point, though I can see why you're considering that given the overall aggressive tone of your messages. Let's backtrack, then. My main point is that scolding an individual for a problem in production is not going to improve the quality of the software produced by a company at all. Do you disagree with that?
Hm, then is your point that many developers become careless while programming because they are in an environment with safeguards in place to avoid screw ups?
nothing in your post was really relevant to this discussion. The fact that it may have been a company policy or that the person wasn't a developer is completely irrelevant to the larger idea. It's literally missing the forest for the trees.
I've been doing software dev for over 20 years and one of the things I'm known for is building very stable systems. Part of the way I do this is by not allowing myself to use these sorts of things as a defense.
When designing and/or building a system I ask: What should not be? Then I build the system to actively look for those situations. Put another way, I don't build systems with the assumption that there are no bugs. Too many developers push the responsibility outside of themselves. As if bugs are inevitable, therefore the fallout from bugs is inevitable. You just do a root cause analysis and move on rather than asking what you could have done differently to avoid the fallout.
I've lost count of the number of times systems I've built have actively refused to do something and then sent out a notification explaining why.
My point here is that you're doing yourself a disservice by insisting that root cause analysis should be enough. Yes it's important, but it's not enough. Some things simply should not be, and they're avoidable.
The problem is that many companies don't really care.