Sometimes hardest part of being dev is staying calm and trying to explain someone why something is a BAD idea, than see being ignored and just silently prepare fix so when shit goes south you can quick fix shit the other dude/dudette fucked up regardless of number of warnings.

Sigh, another dumpsterfire of this variety incoming.

Why fix it for them? Put it in writing, and then assign the fix to them.

If you keep taking ownership of the fix, you're basically giving them a free pass to ignore your advice with 0 consequences, so of course it'll happen again.

@AlmondSauce

Nah, I let production start to be on fire. Also my warnings are in slack, so pretty much in writing.

And when prod explodes somehow I have that fix, ready to push to repo. Than I just sit back with caff and see the burn. I had to intervene once as issue introduced was critical enough it could easly leak data left right and center, and sorry, Im not gonna punish users for coworker's BS

Shit like that happens to me all the time....
I just do whatever boss wants.
But in my line of work a bad call can damage a machine more expensive that many houses :p

For example, had a boss that liked to go behind the workers and increase the machine speed by (50%). But because I changed the programs to work at the speed the tool makers recommend that was already what the machine could work at...
Did it 2 times or 3, first 2 broke the cutting tool, 3rd broke the head of the machine (CNC milling machine). Was just 20.000€ to fix

@GyroGearloose

big ooof