Re:A common trap for people entering programming jobs
by morelisp on Friday June 24, 2022 @06:40AM
(#31859891)
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.
Re:A common trap for people entering programming jobs
by kubanczyk on Friday June 24, 2022 @06:32AM
(#31859846)
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.
Re:A common trap for people entering programming jobs
by 411111111111111 on Friday June 24, 2022 @06:41AM
(#31859900)
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
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.