The fix here obviously is not to call people stupid and boneheaded (which, frankly, I find reprehensible, tbh).
But calling people stupid and boneheaded ain't it, chief.
I didn't call any person or people "stupid" or "boneheaded", so right off the bat you can stop those accusations.
This practice is called "no blame". Often, an error is the end result of a long chain of events, each of which contributes to the error, and blame usually lands on just the last person in the chain.
Yep, it's a great practice that I use whenever I lead a team, in both tech and non-tech settings. However, I've never blamed any individual person and have been speaking of the project team as a whole, so I'm not sure what your point is.
No one understands what led to the mistake, and more importantly, no one really knows how to prevent that same mistake in the future.
I disagree on both counts. While I haven't looked super deep into it, the log4j team seems to be pretty aware of what contexts, decisions, and actions led to the mistake. And, more importantly, it should be obvious to any professional programmer how to prevent the same mistake being made in the future: enforce separation of concerns and don't make obviously dangerous features opt-out.
In this case, the "boneheaded mistake" and "frankly stupid feature", if I understand correctly, came from at least 2 features that interacted in an unexpected way. These features on their own (again, IIUC) are not unreasonable.
I don't think you understand correctly. The library has a feature that executes arbitrary strings. That is an unreasonable thing for a logging library to do. It is doubly unreasonable that such a feature is on by default.
This isn't a case of random features interacting in some unforeseeable way, this is a case of a bad feature that is obviously bad on its face. Sure, there are reasons it is in the library and as a dev I can understand why they put it in the library, but that doesn't change the fact that it was a mistake and shouldn't have happened.
Have some compassion and empathy, first and foremost. Next, give the team support to find out where the mistake happened, and give them space to find a long-term fix for, not only "fixing the boneheaded mistake", but to fix the flaw in the process that led to the entire class of mistakes.
That is great advice for fixing this specific issue, but it misses that this is also a great object lesson for the entire dev community for why design principles exist and how they can help avoid problems like this in the future.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I didn't call any person or people "stupid" or "boneheaded", so right off the bat you can stop those accusations.
Yep, it's a great practice that I use whenever I lead a team, in both tech and non-tech settings. However, I've never blamed any individual person and have been speaking of the project team as a whole, so I'm not sure what your point is.
I disagree on both counts. While I haven't looked super deep into it, the log4j team seems to be pretty aware of what contexts, decisions, and actions led to the mistake. And, more importantly, it should be obvious to any professional programmer how to prevent the same mistake being made in the future: enforce separation of concerns and don't make obviously dangerous features opt-out.
I don't think you understand correctly. The library has a feature that executes arbitrary strings. That is an unreasonable thing for a logging library to do. It is doubly unreasonable that such a feature is on by default.
This isn't a case of random features interacting in some unforeseeable way, this is a case of a bad feature that is obviously bad on its face. Sure, there are reasons it is in the library and as a dev I can understand why they put it in the library, but that doesn't change the fact that it was a mistake and shouldn't have happened.
That is great advice for fixing this specific issue, but it misses that this is also a great object lesson for the entire dev community for why design principles exist and how they can help avoid problems like this in the future.