302
Why I always keep doing it...
(lemmy.ml)
Valid. You need to know if it’s a sometimes bug or an always bug.
The truly terrifying outcome is that it works after changing nothing. Sometimes bugs are the most fun to squash.
We seemingly have a different opinion, what we regard as 'fun' ;-)
Stuff that can't be reproduced and "only" comes up because of some timing issue/race condition is often the most shit to hunt for
I'm currently in such an adventure - and I thought I had it...but the statistics show, that it only got better, but didn't catch all of the occurrences...
Stuff that can’t be reproduced and “only” comes up because of some timing issue/race condition is often the most shit to hunt for
Ah, but if you can't reproduce it, you can just put in an entry of 'could not reproduce' and close the bug report. Case closed. Go home and enjoy a nice beverage.
Tell me that you have never worked on anything even remotely ”mission critical" without actually saying it...
I've worked on "mission critical" things, but that doesn't mean I gave a shit about the "mission". If I'm working for minimum pay, I'm putting in minimum effort. Which means closing the bug report faster and with less effort is always desirable.
I agree with that. The only caveat I have is that if you are a junior, entry level, or even just an underpaid developer being asked to work on "mission critical" code, then that code is not "mission critical". It is code that management is obligated to provide but gives no real fucks about.
Much like a bar mitzvah or quinceañera signals the beginning of the transition from childhood to adulthood, there is the junior to senior transition for developers. It often starts with the realization that the most recent in a long line of super critical bugs you are working on has been sitting around untouched for weeks and is only now "critical" because a customer has bitched about it not being fixed. The best part is when you follow the progress of the bug and see that your fix doesn't get touched by anyone for months because there never was an actual customer bitching about it in the first place, it was just some sales person or VP flexing their power because they felt ignored. So the bug got squeezed it into the already over packed production cycle by making it "mission critical" and assigning it to someone too junior to realize that it's bullshit work.
Happy debugging if it works on the second try... 😬
Best things are, when you throw in some debug output and that changes the timings just as much to not make the bug happen anymore
I've lost more hair to that, than my age...
Well, better than the other way around:
Code works perfectly on your test device but breaks down when deployed to field devices with slightly different timing characteristics or whatever.
Bonus points if it only occurs every few weeks, preferably at night shift and crashes a whole production line... 🫣
(Incident totally fictitious, definitely no people out of this thread involved, just move on, really nothing to see here!)
True that...
Happens too fucking often as well
I'm currently hunting a bug that happens like every 1000 iteration of the thing happening.
Like, I'm telling the hardware to do something and it works pretty much all the time, but over the day, the errors add up
I have no clue why it happens, but can't really turn up the debug logs that much, because with so many things happening, I'd produce like a shitload of data.
But I can't really narrow it down otherwise
And it seems we're in the same kind of shit business ;-)
Real time processes and automation, with customers having problems at night shift, because the maintenance guys during that shift are usually not as good - or it's just bad luck
At one of my last business trips I was already at the airport on my happily way home, when I've got call.
Needed to get my luggage back, new rental car and get a place at the hotel.
Just to discover, that after 15 years the hardware acted up in a way it never did before.
At least I could now include a warning message, if this weird situation ever happens again, but that was a tough one to swallow...
Or the code you are working on is calling a system that is currently unreliable which you cannot be responsible for.
Fuck test automation, it's a fucking trap get out of it as soon as you can
EDIT : that is to say, test automation as in automation that a tester does, instead of unit tests. If you have started a career as a software tester , get out ASAP.
Ofcourse. The first stage is denial.
Very true, especially when working with recursion. (Debugging recursion sucks)
tilts tin foil hat to the left...
Works now 👍
Sometimes, this actually works simply because of your compiler lagged the previous time.
Due to the non zero ammount of times this happened to me... this is like pressing ctrl+c multiple times to make sure you copied the thing. And then pressing shift+ctrl+c cause you aren't sure if that works in this terminal emulator.
The first time, I just saw it's not working; the second time, I was paying attention to the details to see what specific parts aren't working and clues as to how/why.
But sometimes it works the second time because it loaded something in the bg.
Well yes, the trick is to attach the debugger for the second run.
....and because it slows down the execution a bit and this avoids the race condition that triggers the bug, it now runs flawlessly.
And the order of Set traversal in the JVM is different so the other bug also doesn't show up
If the customer isn't running the same debugger i am, i have no sympathy for them. (I'm joking!)
You'd be surprised at how many times this would help. Sometimes data could be in garbage state and would change between execution.
this post was submitted on 11 Apr 2026
302 points (98.4% liked)
Programmer Humor
41934 readers
1 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 6 years ago
MODERATORS