Engineers always present this as a false dichotomy. You can work with other people (and their code) without pissing them off. "Stay the hell out of other peoples code" is no better than "Act with impunity". Thankfully there is a middle ground. It's called talking to people.
People who are the most passionate about programming are the same people who tend to identify with the code their code! If you say the code is wrong, you are also saying they are wrong. You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block. We aren't a group of rockstars writing hit after hit, we are a team of engineers iterating through possibilities and routing around roadblocks.
For dealing with intergroup rivalry you're better off going to the group responsible for that area first to show your results. Get their support before going up the ladder. Let them be part of the success. Otherwise you paint them into a corner when the big boss comes down and says "Why are other teams fixing your problems!?" Now they must attack your solution to justify themselves.
edit: I'm seeing a lot of other threads say "Just don't work at places where this is an issue." When you find robot planet let me know, because this is an issue everywhere. With your customers if not with your co-workers.
"You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block."
Absolutely. In some ways, this is my biggest job as "manager". I try and rotate the team so that no one has "ownership" of a particular feature (we're self organizing but I try and coach people appropriately ;)).
Sure, Bob may have been the person that originally penned a particular method, but refactoring is a fact of life, and it's likely that, if I've done my job right, over time any member of the team should be able to do a given refactor.
What helps is that you explicitly have someone who worked on a particular block of code not fix any bugs related to it. Give it to someone else. They'll figure it out and make any changes.
Have people pair on initial design/architecture (or have specs authored/tweaked by the whole team) so it's never solely one person's vision of how feature X should work.
I've found the best programmers have a zen-like state of detachment with code they've written. Very good, but not great, programmers seem to tie up too much of their identity with their code; transitioning them from "good to great" almost always inevitably requires detachment.
> Thankfully there is a middle ground. It's called talking to people.
> You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block.
Do you have any suggestions for scenarios where this doesn't seem possible? Where any suggestion is treated as an attack, by both programmers, and their manager?
Completely agree. One of the quickest ways to burn bridges and ensure you are perceived as caring more about your own ego and "needs" than anything else, is to re-implement something without talking to anyone about it, be they the authors, stakeholders or 3rd-party dependents. This kind of "look at me, manager! look what I did!" behavior is the cancerous seed of a team ruled by self-seeking and ego.
If your needs would benefit the whole and are not a mere excuse for egoism, but are not aligned with the company/team, get another job.
In the end, the author learned a lesson, but the wrong one. It's not that you should listen when voices of dissent shout in your ear, but that you should simply foster a general environment of open communication, and discourage action-without-coordination.
People who are the most passionate about programming are the same people who tend to identify with the code their code! If you say the code is wrong, you are also saying they are wrong. You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block. We aren't a group of rockstars writing hit after hit, we are a team of engineers iterating through possibilities and routing around roadblocks.
For dealing with intergroup rivalry you're better off going to the group responsible for that area first to show your results. Get their support before going up the ladder. Let them be part of the success. Otherwise you paint them into a corner when the big boss comes down and says "Why are other teams fixing your problems!?" Now they must attack your solution to justify themselves.
edit: I'm seeing a lot of other threads say "Just don't work at places where this is an issue." When you find robot planet let me know, because this is an issue everywhere. With your customers if not with your co-workers.