677
Debugging in a nutshell
(thelemmy.club)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 15 Jul 2026
677 points (99.7% liked)
Programmer Humor
32303 readers
1929 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
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
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.