I don't work in IT/Software Engineering - I work in law. But when I find fault in other's work, it's a courtesy to let them know and give them an opportunity to address it. It's part of being a team player. I am not trying to be critical of you. It's just reading this reminded me of similar experiences where I was in a similar position to you. They were important experiences. People can feel bad when other people fix their mistakes when they aren't given the opportunity to be heard about it. It's so tempting to just say 'I will just do it myself' but you might find other people react poorly to this.

Of course, maybe things are different in the IT world where it may be challenging to identify who committed a buggy change to the code repository, or perhaps just a radically different culture of work. But at the end of the day we are all human.

It does appear you have developed an awareness of this, given what you noted in your reply to him (and props to you for that!). From there on, his behaviour was misguided and not appropriate.

Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code.

People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not.

Bugs/Features can be worked on by anyone without ego getting in the way.

It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it)

The standard you scroll past is the standard you accept.

Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not.

If you contradict them, they cite the common ownership rule and paint you as a non-team-player.

If they introduce bugs into the release and you point it out, you are the villain again.

All in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.

I personally would either point it out or actually leave the project.

We don't have to accept every shitty job as Software engineers.

Unfortunately it takes time to experience and see those issues and to learn to handle them properly.

I do prefer sustainable development and at least my track record shows that it is paying off: high security, high trust in the system, stress-free oncall etc.

If I can't sit in a beer garden on a nice august afternoon a little bit early because everything is falling in peaces I have done something wrong. Not saying that I'm spending all my time not working just saying to have the freedom to be more flexible in when and how I work.

This does demand pushback to management if someone outside of your team starts to sell things with deadlines without asking you.

If the code is owned by 4-30 people, its good.

If the code is owned by 120 people, then it takes way to long to tell what the quality standard is.

> The standard you scroll past is the standard you accept.

The challenge is how to get work done without spending 60 hours a week pointing out or solving code quality problems. To overcome this challenge requires accepting some standard of crappy code.

In best case your team grows and the original hurdles are fixed.

It's always problematic for bad colleges which just do the same mistakes over and over and over again but what do you wanna do? Accept a potential security bug because it is too much effort?

If your code is so complex or big that you have 120 people on it, you should have enough people in governance positions and hierarchical quality gates.

Yes. It is important to have the serenity to accept the things you cannot change.

In the choice between

A. Burning out on a fool’s errand of attempting to fix/prevent all the security bugs.

B. Giving up as you accept that people write security security bugs and as an individual contributor you have insufficient power to stop all of them.

C. Accepting the existence of bugs all around you and focusing on changing the small bits of code that you can.

The latter is preferable.

1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job.

2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures.

I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.

Because I wanted to ask why he would be so mean to you. That insecurity part answers that.

I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place.

The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.

I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up.

But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.

If someone else just fixes stuff for you all the time that just might not be good in the long run.

Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug?

The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible.

What a piece of shit colleague.

It sounds like one possibility is your boss may have been trying to prevent you from getting to his level which would mean he would have to compete with you.

Stack ranking incentivizes people at higher levels to only allow incompetent people to get to their level because they’ll look better in comparison.

What are some ways to do this effectively?

Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?

Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".

Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.

1. Proactively ask individuals for code review.

2. Thank people, visibly and publicly, when they point out mistakes or offer good suggestions.

3. Be an example when you leave critiques; accept that beyond some agreed-on code standards, some things are subjective. Just because you wouldn't write code in a certain way doesn't mean the way they've written it is wrong.

Try to get onto the path of thought that led them there, but let the questions that arise naturally for you hold off as long as you can.

To be clear this is like a policy, you will fail at it but it reminds you of the prinicals that you believe in.

I learn a lot doing this in more ways than i could explain in a book, never mind a comment.

the lessons learned will cover all of existance as you will learn more about how people model the world, problems and solutions beyond the specifics of the problem at hand.

*if doing this drains you make a change of environment (e.g. job), however i find that the discussions you have like this change other peoples thinking more effectively, so its also how you sew the seeds of cultural change.

Your peers aren't harming you by finding fault, they're strengthening your position by doing so.

I personally hate it when a bug slips through to production, and I always profusely thank anyone that spots one before it does. Or after. Whatever, as long as it gets fixed...

If you really wanted to stay with that company because everything else is great, your only chance is to solve this with the boss of the boss.

5 figure bonus lost due to this is abuse.

I disagree that going above your boss first would lead to getting fired though (again with the exception of at will employment).

HR's exact goals vary between companies, but unless the company culture is toxic all the way to the top, part of their job is usually to reduce staff turnover (which is very expensive for the company), and in pretty much any company their job is to protect the company against lawsuits. Abusive managers are not well liked by HR.