[Gibbon1]

> And this was a very brilliant software engineer, but he was consistently making poor decisions like this.

That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions.

> I did my best to shield that software engineer from them

I've found rather painfully that you shouldn't shield guys like that when they go off on their own to make mistakes.

Other thing, you have a team of people that are familiar with how a codebase is put together and does things. And what sort of things go wrong. It's a bad idea to disrupt that 'just because' Goofus rewrites a module to use X fad. Great! Before there were five programmers who knew how that module worked and now there is one programmer who knows how that module works.

[munk-a]

Assuming you are managing a dev (either through a lead role, seniority, or as a manager) you absolutely should shield team members from direct demands from up that chain - that's what most of your job is... Assuming the employee was acting within the rules you've laid out then the you should shield them and consider adjusting your rules to prevent a repeat - if, to contrast, your company has some CI tooling setup and automatic deploys and reviews and whatnot - but then someone edits a file on production... that might be a fireable offense.

Additionally to contrast - if you're a co-worker and not a manager then you may need to examine your relationship (are you a mentor and thus secretly leading them or just a colleague). If a pure colleague makes a mistake you shouldn't stick your neck out too much - except to force your common manager to properly defend them.

Everyone who is fired should be fired by their manager and not anyone else in the org - that's how a team is strong and healthy.

And

Managers, in a healthy company, own the mistakes their subordinates make.

[Gibbon1]

> you absolutely should shield team members from direct demands from up that chain - that's what most of your job is

The other part of your job is keeping your manager informed about subordinates that are being problematic. Up and rewriting a critical piece of infrastructure 'because' is problematic.

[munk-a]

(I'm assuming that you mean that the other person is another subordinate to the same manager, rather than being someone subordinate to you)

It's a bit of a delicate balance. The golden rule is that Snitches get Stitches, but if someone is being unproductive with their time and your manager isn't aware of that fact then letting them know isn't a terrible idea. But it isn't your place to measure how your co-workers are accomplishing their tasks - assuming management isn't out to lunch then performance reviews should fall on their shoulders. Maybe your coworker cleared a rewrite with your manager and your manager was satisfied with the justification and decided that explaining the full reasoning would be a waste of time until the experimental phase was completed.

In theory good management should prevent you from feeling like you need to look over other people's shoulders, because that is their job. So if you are feeling that way you might want to talk to your manager about it, maybe they are bad at managing and are letting things slip through the cracks, maybe they find that allowing someone to experiment with a rewrite is worth the training time - it may be possible that you just need to talk it through with them and find more confidence in their management ability.

[wsc981]

> That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions.

Reminds me that John's Carmack wife told Carmack that she wouldn't allow him to bankrupt the family with his space hobby company (Armadillo Aerospace) :)