This is a really good picture because debugging is always a bigger problem that takes forever to fix
this post was submitted on 15 Jul 2026
540 points (99.8% liked)
Programmer Humor
32306 readers
1754 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 3 years ago
MODERATORS
Reminds me of the Tom & Jerry ep where Jerry tries to keep a stray baby Elephant from being discovered. Tom starts chasing after Jerry but also encounters the Elephant dressed up as a mouse. lol
Let me ask claude to fix it…
20 minutes of insane rambling and wasting all tokens…
Claude: It's fixed. All tests pass ✅
Me: Wait you deleted all tests and the production DB ?!
Claude: You are right to push back. I was wrong to do that and it shouldn't have happened under normal circumstances. I ran the command rm -rf tests sqlite.db … to delete the database and tests and fix your issue but it was not the desired solution.
Me: Help me recover the database.
Claude: I can't do everything for you. Be a real engineer and do it yourself.
I like how, as someone else put it, all these AI responses exhibit sociopathic tendencies which reflect the elite caste that is pushing for them.
The idol statue reflects the woodcarver who made it.
Story time. At a place I worked we used Entity Framework + LINQ a lot. There was probably 10,000 different queries server side written this way.
One day I noticed a problem with one of the queries. It was reported that it would fail intermittently. Investigate. Oh ok it's broken because the left join is returning nothing in some cases and it's not handling that properly. That's strange though, I don't see anything immediately wrong with the code…
Oh… oh no… after we updated to .Net Core 6, all the left joins in the entire enterprise system are broken when the left side returns nothing, and it will just crash. Isn't that the whole point of a left join? We didn't notice for months because it only happens 5% of the time (the left joins were basically fail-safes for unusual database states). We can't revert to .Net 5 because it's end of life either.
Surely we can't have that many left joins though right? CTRL+Shift+F. Oh no. Plus the most complicated and important Do Not Touch ^TM^ queries are broken.
Hence we set off on the quest to rewrite all 10k queries from LINQ to raw SQL. This was before A.I. mind you, so it was a manual and tedious process. I would have used the raw SQL output inspector feature but that was also broken. This is one of the few times I would absolutely love an A.I. to do this for me, and I can just review and test each function at the end.
Fuck Entity Framework. I left a report on their GitHub, but people were just bitching as usual about how hard it is to fix it to work like it used to. A few weeks ago, 5 years after the original problem, and I no longer work there, I get an email that it's finally fixed. Hooray.
Circa 2005 I created a mobile app (for the honest-to-god-that's-what-MS-named-it "WinCE" OS that later became Windows Mobile) that allowed workers to survey power line networks in the field and indicate all the trees that needed to be trimmed or removed. The app used a local SqlCE database and the workers would upload their recorded data at the end of the day back in their hotel rooms using Remote Data Access, an MS technology which allowed SqlCE databases to "sync" with a master Sql Server database.
It almost always worked flawlessly (100% during development, natch), except for once in a while when synced data would somehow end up in a weirdly corrupted, mangled state on the central server. Like, records that were lacking a primary key value (!), something that is basically impossible to achieve. I opened a ticket with MS support and we went back and forth on this for a few weeks until they basically said "yeah that's fucked" and recommended that I modify my app to sync the same data multiple times to ensure it made it to the server correctly.
I actually had substantial faith in MS products up to that point (facepalm).
The moral of the story is to always just write the damn SQL and stop fucking around with ORM and frameworks and all of it. 😅
It's funny, I know exactly zero programmers (and this includes myself) who didn't initially encounter SQL and decide it was clunky and stupid and try writing their own classes to write the SQL for them. I want to think it only took me a few weeks until I understand its actual value and purpose but I'm probably misremembering my past. The worst I ever saw, though, was a coworker who tried writing his own ORM. He had one project with classes named "AND.cs" and "OR.cs". All they did was take an input string by reference and append " AND " or " OR " to it respectively. I'm sure I never before or since encountered a class that did less work.
Yup. I haven't touched .NET in forever ... like it's been 7 years or so but I was there for the 1.0 days. I remember running stuff to code gen db tables to objects and NHibernate and Entity Framework and all that jazz.
I was just like, "wait, why am I writing all of this if it's just a projection". Then the Active Record pattern felt limiting when scaling my application. I think after we discovered Dapper... we just stuck with that. It's a micro-ORM where we write SQL and it maps into C# objects and it just simplified when hydration happens and how. (not sure how much its changed or if it's even active now, but it was amazing)
Yep… I love writing SQL actually, I find it very elegant and interesting. It wasn't my original decision to use EF, so I used the incident as an excuse to pivot to raw SQL constants with parameters. Never had another issue. Plus you can just copy paste the SQL into a debugger and directly view the output and optimisation paths. We also had this thing where the first web form request to an instance would take 15 whole seconds as it loaded the entire EF context model and relations into memory, and there was no tricks or traps to fix that at the time. Customers weren't happy with that answer. Good ol' SQL though, can't fuck up that implementation
As long as everything is properly sanitized and parameterized, I agree. Or use an extremely lightweight orm like dapper that basically has you write SQL inline and mostly just does dynamic model binding.
I only need ORM to have the flexibility of DSL table modeling for repeated fields. Think, createdAt, updatedAt, id (and the PK that comes with it), etc. After the migrations are written, I prefer to use a query builder
Was it HL2 or TF2 that had the load bearing .jpeg of a banana that would cause crashing if removed? 🤔
It's tf2 and a coconut instead of a banana, but yes, game doesn't run without it.
Apparently TF2 added a "community-generated" map last week that was not only broken itself, it broke other maps too, causing game crashes.
The issue was a model of a row boat that was added to the official game in 2009. cp_premuda was added to the official game in July, 2026. But Premuda is a lot older than that, and it references a version of the row boat model that is older than what was added to the game in 2009.
They also added a map that let you build in spawn which let spys teli in. They probably fixed it though.
Yes, one of those. Even came with a warning
Yeah the big guy is the systemic problem that's in the org creeping in as tech debt
Or the architectural problem, because your precursor was an idiot.
... which is true even in cases where your precursor was yourself.
Especially true then.
Looking at a codebase going which fucking idiot wrote that, when there's only one, me
When you make big structural changes to the code but it compiles somehow:
I had a coworker on one project that took input as short integer values between 0 and 32767. The values conceptually represented min and max values between 0.0 and 1.0, so one day he changed all the parameters to Float, like in hundreds of places. Since the application then wouldn't compile, he wrapped all the calls via search-and-replace so that the integer parameters were cast to Float and then clamped between 0.0 and 1.0.
Viola! the application then compiled. Unfortunately, this application controlled a baseball-throwing machine capable of 125 mph and he decided to test his new version (for the very first time) on an actual baseball field with Little Leaguers on it. The machine's first throw was supposed to be a soft ground ball to the shortstop, but was instead a 125 mph knuckleball a foot above the kid's head. This lead to the only time in my programming career when I had to physically intervene to prevent a fistfight (between the client and my manager).
Sometimes its also just a typo
