[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.