3 ms·

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsense and second because it avoids having people that are single points of failure (only one to work on this part of the code). I would consider toxic a work environment where somebody would talk about "my code" after it's been merged.

Silhouette 8y ago
That's an idealised position, but not always a realistic one. Having specialists who understand certain parts of a complicated system better than anyone else is often valuable. Beyond a relatively small size of project, no-one can be an expert on everything, and a "shared code ownership" strategy where all code is communally maintained may leave you with no true expert when you need one. The underlying problem here wasn't really that someone "owned" that code, but that when someone else did have a useful suggestion to make, politics overrode technical merit. Clearly that had been happening for a long time and resulted in several other potentially useful contributions by others being wasted as well. This seems to be a problem of toxic management culture, not a flaw in the technical processes.
- rileymat2 8y ago
  Don't projects like Linux use a system of module ownership/lieutenants?
dktp 8y ago
Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it". In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important. I do not consider my work environment toxic at all. Just an agile startup
- khalilravanna 8y ago
  I think you’re both in agreement. “My code” when it’s a bug is fine because you’re really showing humility and responsibility. I think it is the one exception to “our code” being used as the standard way to refer to code. When the code is great it should be “our code” and by proxy the team’s success. Not one person’s. And when there’s a bug that’s not your own it should be “our bug”. You don’t want to throw anyone under the bus because we all make mistakes. (That’s not to say all bugs should be ignored. Your team should investigate why their code failed and how they collectively can learn.) I think the “my code; my bug” thing is great because if you lead by example people will follow suit and take responsibility for their failures as well. I think that’s a great effort to move towards a more positive culture.
- StavrosK 8y ago
  It's fine if you yourself want to take blame for some code you wrote. It's not fine if someone else wants to blame you for it. You wrote it, but someone else reviewed it, and (probably) still someone else tested it and yet someone else released it. It's a team effort.
  - deleted 8y ago
    [deleted]
crimsonalucard 8y ago
It's not that simple. People have pride despite what they claim. If I rewrite an entire feature that someone did just because i think my way is better, you gotta be smart in how you think that should be done. Respect other people pride and work or dont expect them to respect yours.
- sanderjd 8y ago
  It's definitely bad for pride and politics to hinder progress, but a bit of tact often goes a long way.
- midasz 8y ago
  Hero-culture is practically the same as blame-culture.
wpietri 8y ago
Agreed. Of all the Agile practices, collective code ownership is possibly my favorite. It requires that one proceed thoughtfully, of course. And I think it requires other practices, like high test coverage. But I think people treating patches of code the same way dogs defending their yards is poisonous. It's hard enough to get good work done without every pull request hinging on politics.

Silhouette 8y ago

That's an idealised position, but not always a realistic one. Having specialists who understand certain parts of a complicated system better than anyone else is often valuable. Beyond a relatively small size of project, no-one can be an expert on everything, and a "shared code ownership" strategy where all code is communally maintained may leave you with no true expert when you need one. The underlying problem here wasn't really that someone "owned" that code, but that when someone else did have a useful suggestion to make, politics overrode technical merit. Clearly that had been happening for a long time and resulted in several other potentially useful contributions by others being wasted as well. This seems to be a problem of toxic management culture, not a flaw in the technical processes.

rileymat2 8y ago
Don't projects like Linux use a system of module ownership/lieutenants?

dktp 8y ago

Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it". In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important. I do not consider my work environment toxic at all. Just an agile startup

khalilravanna 8y ago
I think you’re both in agreement. “My code” when it’s a bug is fine because you’re really showing humility and responsibility. I think it is the one exception to “our code” being used as the standard way to refer to code. When the code is great it should be “our code” and by proxy the team’s success. Not one person’s. And when there’s a bug that’s not your own it should be “our bug”. You don’t want to throw anyone under the bus because we all make mistakes. (That’s not to say all bugs should be ignored. Your team should investigate why their code failed and how they collectively can learn.) I think the “my code; my bug” thing is great because if you lead by example people will follow suit and take responsibility for their failures as well. I think that’s a great effort to move towards a more positive culture.
StavrosK 8y ago
It's fine if you yourself want to take blame for some code you wrote. It's not fine if someone else wants to blame you for it. You wrote it, but someone else reviewed it, and (probably) still someone else tested it and yet someone else released it. It's a team effort.
- deleted 8y ago
  [deleted]

crimsonalucard 8y ago

It's not that simple. People have pride despite what they claim. If I rewrite an entire feature that someone did just because i think my way is better, you gotta be smart in how you think that should be done. Respect other people pride and work or dont expect them to respect yours.

sanderjd 8y ago
It's definitely bad for pride and politics to hinder progress, but a bit of tact often goes a long way.
midasz 8y ago
Hero-culture is practically the same as blame-culture.

wpietri 8y ago

Agreed. Of all the Agile practices, collective code ownership is possibly my favorite. It requires that one proceed thoughtfully, of course. And I think it requires other practices, like high test coverage. But I think people treating patches of code the same way dogs defending their yards is poisonous. It's hard enough to get good work done without every pull request hinging on politics.