On the other hand, my company previously had strong code ownership where a small team owned each module, and rearranged a few months ago where we have collective code ownership.

The problem is that so many of the pull requests I see are people who have little understanding of the domain specificities of our old module, and the architecture of it. I see drive-by pull requests which, if they went in as is, would look very sloppy in this clean module we spent so long building.

Is code ownership always bad? Martin Fowler has an interesting dynamic he calls weak code ownership - a team (or person) is responsible for a module, but other teams can change it, although larger changes usually would involve consultation.

I've always heard the notion that being possessive or territorial about a section of code is bad. But our old team spent over a year building a nice clean module, and the pull requests coming in could do substantial damage in one merge to something we spent over a year making nice and clean. I don't block people from doing work but I do hold up pull requests touching our old module until they clean up what they're doing.

Also - some of what is coming in is from consultants who might not be around in six months, and are a drive-by pull request where they may never touch our module again. So spending time educating them and so forth would be a waste of time. The handful of people who will be working with the module on a more ongoing basis I have spent more time educating, helping and bringing in.

https://www.martinfowler.com/bliki/CodeOwnership.html

(also -

https://signalvnoise.com/posts/3023-why-programs-become-territorial

https://www.freecodecamp.org/news/why-code-ownership-sucks-and-you-should-never-work-somewhere-that-practices-it-b8fc1c694074/

https://www.coderhood.com/12-reasons-avoid-individual-code-ownership/ )