3 ms·

> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we

> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. 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!

JohnMakin 11mo ago
sandbagging or messing with metrics is an inevitable part of playing a role in $BIGTECHCO. Even if people don’t admit it or aren’t aware of it, it happens everywhere. If anyone resents it they just resent you’re doing it better than they could. much of what we do is all a political game. I’ve had situations where I cannot do something that clearly needs to be done, I in the past will find reasons to slow things down and point to (thing that needs to be done) as the reason why. Eventually the manager above you will prioritize it or discipline you. If you’re right and are valuable and your manager isn’t stupid, you’ll get your way, and they can take credit for the sudden velocity gain. I’ve also done the opposite in speeding things up to expose brittle unsustainable processes. 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.
deleted 11mo ago
[deleted]
sfink 11mo ago
> Well, I don't know that we can separate external forces from why people might dislike bad code... 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.

JohnMakin 11mo ago

sandbagging or messing with metrics is an inevitable part of playing a role in $BIGTECHCO. Even if people don’t admit it or aren’t aware of it, it happens everywhere. If anyone resents it they just resent you’re doing it better than they could. much of what we do is all a political game. I’ve had situations where I cannot do something that clearly needs to be done, I in the past will find reasons to slow things down and point to (thing that needs to be done) as the reason why. Eventually the manager above you will prioritize it or discipline you. If you’re right and are valuable and your manager isn’t stupid, you’ll get your way, and they can take credit for the sudden velocity gain. I’ve also done the opposite in speeding things up to expose brittle unsustainable processes. 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.

deleted 11mo ago

[deleted]

sfink 11mo ago

> Well, I don't know that we can separate external forces from why people might dislike bad code... 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.