- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
You must log in or register to comment.
If you don’t understand how and why, it’s broken.
It’s a load-bearing function.
We have no idea why it’s important, just that it is critical to everything functioning.
One of my favorite Simpsons lines, the load hearing poster
I feel like the “we don’t know what this function does” meme is kinda bad. There’s no reason beyond maybe time crunch why you shouldn’t be able to dissect exactly what it does.
Despite this, the notion of a load-bearing function is still very relevant. Yeah, sure, you know what it does, including all of the little edge case behaviors it has. But you can’t at this time fully ascertain what’s calling it, and how all the callers have become dependant on all the little idiosyncracies that will break if you refactor it to something more sensible.
It has been several times now where a part of my system of legacy code broke in some novel fantastic way, because two wrongs were cancelling out and then I fixed only one of them.
https://en.wikipedia.org/wiki/Fast_inverse_square_root
even if you can figure out specifically WHAT a function does, it’s not always clear WHY a function does, and honestly, if this function wasnt labeled in the code, no way in hell would I know what it does.
It has an entire wiki page dedicated to explaining it, and it involves enough math that most people wouldn’t be able to follow along.
Nothing this atrocious lives in any current codebases I work on… but if you work at an old enough company, some of the load-bearing code will be tricky to figure out what is calling it, but also it was written in a time where little hacks were needed to eke out performance.
You only have to experience it once for it to be a memorable enough thing that you will cite it for the rest of your days.
Or more realistically, it IS comprehensible, but the level of effort necessary to comprehend it is not worth it. So you leave it as “undecipherable” and move on.
There’s no reason beyond maybe time crunch why you shouldn’t be able to dissect exactly what it does.
Usually it’s mysterious business logic from before the dawn fo time.
Before January 1, 1970?
Exactly.
Sometimes its either ship something broken or lose your job.
Lose a little credibility now, or a ton of credibility later? Sounds like a pretty short-sighted tradeoff, and a good opportunity to find a less shitty employer.
You’re thinking like someone who exists beyond this quarter’s profit margins.
I mean, you do, but as your boss, I’m required to tell you that you need to maximize short term results, and take all the responsibility for medium and long term calamities caused by me telling you to do that.
You’re not gonna be my boss for long with an attitude like that.
It sometimes depends on the programmer’s situation. Maybe its “lose a ton of credibility or live on the street/lose your H-1B Visa”
I admit that I’m currently in a position of privilege where I don’t have to worry about immigration status or insecure housing. I do try to use my power to shield those less fortunate.
But, losing a little credibility now buys everyone time for their job search!
Precisely. I was remembering someone else’s complain on a co-worker thay had. It was bad for this reason(s), and to make the situation even more infuriating they were able to sell themselves quite well. So they changed jobs, always ‘capitalizing’ on their frauds…
What if all the tests pass?
If the tests don’t give any insight into the functionality it is testing, they are probably not the best tests.
If the tests pass, then everything is fine… Unless we expected the tests not to pass…then it’s time to burn the codebase down and try again after a long vacation to clear our heads.
Of course, I’ll usually settle for fixing the test suite after a long weekend. But in my heart, I’ll know what I should have done…
…or you can just delete the failing tests :)
Work smarter not harder
Let it Be? No, no. Let it Haiku.
