[mjthompson]

Clearly he's got some issues given the reaction. However, was he informed of the bug? Was there an expectation he would fix his own mistakes?

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.

[plorntus]

Not the original poster but I think things are just radically different by the sounds of it. Every company I have worked at, once the code is in the main revision everyone is responsible for it. At that stage the code has gone through many people from reviewers to testers, its not one single persons fault.

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.

[cube00]

This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team.

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.

[valmarket]

This only works if the team has a very high standard and some self restraint.

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.

[Hajuijj]

This sounds like a leadership issue.

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.

[mjthompson]

Very interesting stuff to read from the perspective of an unenlightened outsider.

[afarrell]

This works up util a point.

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.

[Hajuijj]

I think it is worth it in the lo g run.

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.

[afarrell]

> what do you wanna do? Accept a potential security bug because it is too much effort?

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.

[quanto]

No offense taken. Your questions are valid.

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.

[ozim]

Thanks for following up.

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

[Aeolun]

I understand the insecurity part, I don’t understand the behavior. Or maybe I do, I just consider the person an asshole first, and insecure second.

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.

[Hajuijj]

One point though: i personally don't like that as well as I see my bugs/issues as something I should fix.

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.

[efficax]

Software is a machine. You don't ask the other mechanics if you can go and replace a faulty part on an engine they rebuilt last week. The engine is broken, you fix it and move on.

[Hajuijj]

I would still expect communication. After all I don't want someone else to take away a potential learning experience.

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

[david38]

The bosses behavior is the worst I’ve ever seen.

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.