4 ms·
> can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day
by fredsir 10y ago
> can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
If that is something that has to be done a couple of times in a projects whole life, fine. If that is how bugs are solved all the time or frequently, I can only imagine how bad the codebase will be to maintain in years, and how depressing a job it must be to work on it.
That line of thought bleeds that no-one cares about the project, and only cares that the "people paying for it" hopefully don't notice the state of affairs underneath, and that they are not in a position to switch away from the product when ultimately it burns, which it will, if that is how bugs are treated. It bleeds that money is the only incentive, not heart, not passion, and that's just sad. It's why so much software is so bad and ends up costing much more in the long run than fixing the damn bugs properly right now, either because you end up having to maintain it until death, because it's so hard to maintain, or because you can't keep increasing customers after years because the product is now in such a bad state that time is spend fixing/hiding bugs instead of adding new features or improving existing ones.
> ultimately we aren't paid for technical excellence but for working programs.
That is true for most people and most projects, unfortunately. Bugs should not be covered and hidden away, they should be fixed.
- TimJYoung 10y agoI had the same reaction as you to this post, so thank you for nicely summarizing my thoughts. I'll just add: To me, the main distinction is this: you must at the very least figure out the reason for the unwanted behavior. If you don't, then you really have no idea whether your quick little fix covered up something important or not. It's one thing to investigate, find out the cause, and then say "meh, that's way too expensive/time-consuming to fix, so we'll switch libraries/3rd party code or just remove the requirement for the special scrolling". It's quite another to just say "meh, display: none, look at how productive I am !". I've had other developers do this in front of me, and it freaks me out to no end. One sat there and told me that if he changes a month calculation to subtract a month, then the total comes out correctly. I asked him why that was and he said "Why does it matter, I'm getting the right result ?" We all need to remember that we're not being paid to type, we're being paid to think.
- BurningFrog 10y agoYour thought has a name: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
- TimJYoung 10y agoBeautiful, thank you.
- sbov 10y agoReminds me a bit of https://en.wikipedia.org/wiki/Programming_by_permutation https://en.wikipedia.org/wiki/Programming_by_permutation
- LoSboccacc 10y agoIn a third party library which already touches a sensitive area that shouldn't messed with in the first place? That'd be a week of two of work, easy. Means reaching a client less. No way I'm gonna chase the white rabbit in its hole to fix something that has no side effects and zero ripercussion on other components.