4 ms·

> There is no love and loyalty between employer and employee. I don't think anybody here talks about employees caring about or loving their employer. It's abo

> There is no love and loyalty between employer and employee. I don't think anybody here talks about employees caring about or loving their employer. It's about about worker caring about their work. Because if I don't care, this is what happens: if input == input_that_causes_bug_1948348 { return static_output_for_bug_1948348 } Add UT. Next ticket please.

411111111111111 4y ago
Well, if a given architecture doesn't allow for another solution, that might be the only implementable choice. Remaking the core architecture to solve an obscure bug which only happens when you've got overlapping leap years and leap seconds is most certainly a bad decision. For a simple example: Phillips hue movement detectors don't work for a very short time before new years. (My guess is that they're validating the year for the activation signal). I don't know how the bug occurs, but i can imagine several ways in which this could become unfixable if a given architecture was chosen... I still want it to work though, so I'd really like it if they'd just added something like your example.
- kubanczyk 4y ago
  How about these implementable choices for a dirty fix: - make lightbulbs work in these last seconds of the year 2022 and only that year - make lightbulbs work in the last seconds of years 2023-2036 or more This is the distinction I've been trying to make: there are sometimes powerful incentives pushing workers into the former, even if the latter could be approximately the same effort.
  - 411111111111111 4y ago
    Ah, I misunderstood your example in that case. I was thinking more about solving it at the source vs essentially just catching the error case and overwriting the behavior. And while the latter is definitely "code smell"/technical debt... Sometimes, there aren't really any good solutions to a given problem
- morelisp 4y ago
  I think it's more likely you just haven't been in a company with coworkers who write this kind of code chronically, and also opt out of any participation in architecture meetings or design reviews. Just interminable finger-pointing and stop energy any time there's some critique.
cardanome 4y ago
> It's about about worker caring about their work. Eh, nearly every worker will given the time and ability will do the proper solution. I have NEVER seen "workers caring" to be an issue in practice. The reason code starts to smell is nearly always management. If boss says to quick fix, quick fix it is. The fish always rots from the head down.

411111111111111 4y ago

Well, if a given architecture doesn't allow for another solution, that might be the only implementable choice. Remaking the core architecture to solve an obscure bug which only happens when you've got overlapping leap years and leap seconds is most certainly a bad decision. For a simple example: Phillips hue movement detectors don't work for a very short time before new years. (My guess is that they're validating the year for the activation signal). I don't know how the bug occurs, but i can imagine several ways in which this could become unfixable if a given architecture was chosen... I still want it to work though, so I'd really like it if they'd just added something like your example.

kubanczyk 4y ago
How about these implementable choices for a dirty fix: - make lightbulbs work in these last seconds of the year 2022 and only that year - make lightbulbs work in the last seconds of years 2023-2036 or more This is the distinction I've been trying to make: there are sometimes powerful incentives pushing workers into the former, even if the latter could be approximately the same effort.
- 411111111111111 4y ago
  Ah, I misunderstood your example in that case. I was thinking more about solving it at the source vs essentially just catching the error case and overwriting the behavior. And while the latter is definitely "code smell"/technical debt... Sometimes, there aren't really any good solutions to a given problem
morelisp 4y ago
I think it's more likely you just haven't been in a company with coworkers who write this kind of code chronically, and also opt out of any participation in architecture meetings or design reviews. Just interminable finger-pointing and stop energy any time there's some critique.

cardanome 4y ago

> It's about about worker caring about their work. Eh, nearly every worker will given the time and ability will do the proper solution. I have NEVER seen "workers caring" to be an issue in practice. The reason code starts to smell is nearly always management. If boss says to quick fix, quick fix it is. The fish always rots from the head down.