In my defense, we trusted the input. But that's post-rationalisation, because I simply didn't know what I was doing at the time.
It gets worse. If I'd done it properly, my senior would have beaten me up in code review for "complexity". That was a man who would never use a screwdriver when a hammer was already in his hand.
His defense? "This system is internal only and never connected to the internet"
Senior titled devs don't necessarily know their shit.
If you promote the competent people, you leave the incompetent ones to do the actual work.
Breaking it down: That the most diligent / irreplaceable people who know the guts of the machine tend to be chained to their roles with occasional raises seems fairly logical from a C-Suite perspective. The tendency to promote incompetence - particularly overconfident incompetence - is the part that bears more scrutiny. If it were isolated to a few companies, it wouldn't be so relatable. I have a theory that it has to do with certain kinds of communication skills (specifically, bullshitting), being selected for in certain roles. And being able to write good code and explain why it has to be done that way requires the opposite of bullshitting.
The database has access control right? So only a few people in the org can read the data. And you are imagining a case where they:
a) find an inverse image of a password hash and use that login as another person to do something bad.
b) reverse the password from the hash to use in another context.
If a is an issue, why does this individual have sensitive data access in the first place? b is still unlikely. Any inverse image is unlikely to be the password if there is salting.
It sounds like an improvement could be made, but maybe not the highest priority. Can you inform me?