If you don't understand how and why, it's broken.
this post was submitted on 30 Jan 2025
926 points (98.0% liked)
Programmer Humor
20215 readers
1670 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
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
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.
Lol, welcome to the party. I'm not in a programming position, I'm on a systems engineering team. Most of my team mates can do some PowerShell scripting, but I have some programming classes under my belt.
I have a PowerShell script that is complex enough that I'm confortable calling it a program instead. Roughly half of the code is comments or logging the program flow. Every run generates a step by step log of all actions taken. I have 2 Word documents that summarize the process to different levels of detail, and a fucking flowchart for the visual peeps.
I'm still treated as the only person who could possibly flip the clearly labelled read only and route email to our team only switches and troubleshoot it.
To be fair, I recently learned during a vendor meet and greet that the vendor's tech guy in the meeting had previously made a consulting firm to sell exactly what I built this program to do. Probably means I'm in the wrong line of work.
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…
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.
Js ?
I also tend to be writing code for embedded systems, so most dependencies are non-starters.
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.
If you're gonna do that it should only be after sending a very blunt CYA email.
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.
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.
Hahaha, I'll do whatever you want boss, but you're sorely mistaken if you think you're getting away without a written record of you signing off on telling me to do stupid shit.
You're not gonna be my boss for long with an attitude like that.
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...
It's never the nameless developer's credibility that is being harmed.
Pretty much. These commenters seem to believe engineers are given all the resources needed to deliver everything in time in perfect condition.
If you don't, you quit. See Boeing.
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.
In a room full of dickheads, it's often the loudest dickhead that gets their way. Often it's the CEO.
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?
My tests always pass! They've never failed, that's how good a programmer I am!
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
Delete all the tests!
Let it Be? No, no. Let it Haiku.