Not endorsing it, but, it just seems to me the way most performance management works at these companies (I came from a company that liked to think it was amazon with stack ranking) you have to do it or you will get shanked inevitably before you vest. This is just my personal experience. TLDR it’s how you make things “happen”
It’s very cynical. Thankfully these days I work on much smaller teams where everyone helps as much as they can because you’re constantly treading water, but there’s very little room for this kind of political maneuvering and bs.
I'm not denying the validity of the reasons stemming from external forces. I'm just enumerating a bunch of additional reasons why developers might have a problem with bad code.
>> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
> Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
Heh. That's definitely a valid and common reason for resentment, but again I think the resentment can arise from more internal reasons as well. Even the craft coders recognize that you can't polish forever, and if one person spends 90% of their time polishing, then effectively that requires the others to pick up the feature work slack. That person is leaning on the rest of the team. It might be sometimes the right thing to do, but if it's a perennial pattern then even a team with 100% anal-retentive craft coders is going to get annoyed. Possibly because it cuts into their polish time, so they end up shipping worse code than they'd like.
But then, I'm not sure we're even disagreeing. The above could be labeled as "cultural". I think of the internal/external distinction as one where it's internal to the team vs imposed by management.
Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life, and the reality is that your livelihood might depend on meeting those expectations. If you like programming, you might also like maintaining or refactoring code; it goes with the territory, and it can be fun to see how something can be improved or challenge yourself to see how far you can improve it. But it tends to be less enjoyable when your ability to eat and house yourself rides on someone else's bad code.
> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.
Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.
> Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not.
Agreed!