- 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.
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.
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…
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’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.
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.
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.
I feel like these memes have to (mainly) stem from badly documented or broken libraries. The only times where I don’t understand what I’m doing are when I try to figure out what someone else is doing
Dependencies suck
I once saw something about how if you are trying to build it yourself instead of using a pre-existing library you come off arrogant.
Can I build it better? Probably not. But do I want to deal with a dependency in my fun side project (unfun), when I could just build it myself (fun)? No.
I probably should to get more practice with it so it is less painful, but…
The most recent library I wrote for my team at work is painstakingly documented, and everyone has been invited to the multiple recorded training sessions.
They still act like it’s black magic and just push all work and questions to me.
You must not have worked for a dickhead expecting you ship software on Monday that takes months to write when you were given a week to do it.
No, it’s usually ship on Friday. At 1600.
The trick is to be the bigger dickhead.
You may be joking, but as long as you’re actually good at what you do, being a dickhead can be a winning strategy.
I’ve never been able to do it myself, but know many who have.
I do try to reserve it for when I’m fully confident that I’m correct.
In my experience, people that aren’t easy to work with that aren’t already in charge don’t stick around very long.
I’ve always managed to find fresh people that didn’t have their priorities backwards.
What if all the tests pass?
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
If the tests don’t give any insight into the functionality it is testing, they are probably not the best tests.
Let it Be? No, no. Let it Haiku.
