Having experts on specific modules of the projects is a good practice, but anyone can chip in anytime (code reviews, peer programming, bugfixing), there are many ways to mitigate the ownership problem.
You do not fully understand a system until you have a lot of experience with it (for example owner of the wrappers for a specific database).
You do not want all your employees to know all your 100 microservices by heart.
There are too many generally examples, for example not all Teams are better then 1 solo working, just put 3 juniors with 1 senior and you'll see that everything will go apart.
Code ownership is bad ofc, I only saw this behaviour at old projects/companies, with mediocre developers that thought this way they will make themselvs more valuable and the company more dependent on them. They were wrong ofc, it's far better to make yourself useless (example automate everything), this way you can solve other problems too, adding more value, getting a bigger paycheck, win/win. Most important, the companies I saw were not technical, the devs were just "some dudes in an office that do magic". But again these kinds of developers do not read these kinds of articles, because they do not want to improve.
And.. I can keep going, but is no use, it seems that ppl like these generic articles that describe a fantasy world, so I'll go in my corner and shut up.
Yes this article seems to paint a fantasy world. In the real world I rather imagine managers like this approach because they can force a poor guy carry the whole team by having him firefight areas other make a mess of. And the managers not have own up to their hiring mistakes or decisions or deal with the actual problem of low quality devs which may be forced on them by upper management which doesn't want to hear about paying better salaries and not hire the first guy that comes to an interview. So this way of working with everyone owning the problems(and the manager getting the credit) is a great way of sweeping the problems under the rug and not making "waves" which is what most management wants.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Altrough there are valid points, this article is taken too far in extremes to prove your point, but I read a nice story about a such example: "We fired our top talent, best decision we ever made"
Having experts on specific modules of the projects is a good practice, but anyone can chip in anytime (code reviews, peer programming, bugfixing), there are many ways to mitigate the ownership problem.
You do not fully understand a system until you have a lot of experience with it (for example owner of the wrappers for a specific database).
You do not want all your employees to know all your 100 microservices by heart.
There are too many generally examples, for example not all Teams are better then 1 solo working, just put 3 juniors with 1 senior and you'll see that everything will go apart.
Code ownership is bad ofc, I only saw this behaviour at old projects/companies, with mediocre developers that thought this way they will make themselvs more valuable and the company more dependent on them. They were wrong ofc, it's far better to make yourself useless (example automate everything), this way you can solve other problems too, adding more value, getting a bigger paycheck, win/win. Most important, the companies I saw were not technical, the devs were just "some dudes in an office that do magic". But again these kinds of developers do not read these kinds of articles, because they do not want to improve.
And.. I can keep going, but is no use, it seems that ppl like these generic articles that describe a fantasy world, so I'll go in my corner and shut up.
Yes this article seems to paint a fantasy world. In the real world I rather imagine managers like this approach because they can force a poor guy carry the whole team by having him firefight areas other make a mess of. And the managers not have own up to their hiring mistakes or decisions or deal with the actual problem of low quality devs which may be forced on them by upper management which doesn't want to hear about paying better salaries and not hire the first guy that comes to an interview. So this way of working with everyone owning the problems(and the manager getting the credit) is a great way of sweeping the problems under the rug and not making "waves" which is what most management wants.