You must log in or register to comment.
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.
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.
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. 😅
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
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.
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
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.
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.
Sometimes its also just a typo
When you make big structural changes to the code but it compiles somehow:
