Stop making "aesthetic" changes in modules you're not working in. Your naive "add proper..." commit just brought down the whole system.
Thank you for half a day wasted and a pissed of client.

What if one's allergic to ugly code?

@silkfire Ugly, working code is better than nice, buggy code.

If you're working on something and beautify a bit, then test all changes thoroughly and everything works fine, that is OK.

But changes just for fun, without real need and not testing enough, leaving it buggy, is almost sabotage.

@silkfire Valid question haha

There ain't no alternative to aesthetics though.

But, yeah, stay in your lane: Stop making changes on what you're not working in . . . Stop it.

Ugh, we have a junior who's obsessed with editing other people's code to "look better" and write packages that someone else in the company has already written because their package is "my way".

You're not being paid to waste time.

I have an obsession with editing exception messages to make them super clear and contain useful information. Does that seem wrong?

@stonestorm That junior needs quite a bit of micro-managing.

Snowflake Server?

@TheCommoner282 The point is not just making code changes behind other people's back, but then not fucking testing the changes.

@TheCommoner282 It is behind other people's back because it's obviously a junior who did not know what he was doing. And no, bugs don't just happen, this was sloppy work because he didn't test, and that's a no-go.

@TheCommoner282 It wasn't hidden, but it was also not discussed with someone who is familiar with this module. There is no "my code" in our repo, everyone has the right to make changes anywhere if necessary. But if someone is making changes in modules he usually doesn't work with, he should check with someone who does.

And I know that this changes hasn't been tested, because I know this guy doesn't know how he could test the runtime behaviour. Maybe it was because the change was really minor, but introduced a big anyway.