And the worst part is when it actually does and you have no fucking idea what went wrong before.
111ReplyThe pc had the hiccups and now it's fine. Problem solved!
30ReplySome times my game engine needs a wake up run, then an actual run.
8ReplyIt works on my machine!
1Reply
Blame cosmic rays.
1Reply
That's step zero: rule out black magic
99ReplyThose damn cosmic rays flipping my bits
56ReplyPlease tell me you look skyward, shake your fist and yell damn you!!!!
9ReplyI wonder if there's an available OS that parity checks every operation, analogous to what's planned for Quantum computers.
4Reply
That feeling when it is, in fact, computer ghosts.
14Reply
Me: "Hmm... No... No the code is good, it's the compiler that's wrong."
runs again
71ReplyNo no it's the environment. Just need to push to production to make sure it's nothing else. No worries, it's a small change.
38ReplyIt'll be done soon, then I can go home. TGIF, am I right?
12Reply
Yeah, but sometimes it works.
57ReplyIt's even worse then: that means it's probably a race condition and do you really want to run the risk of having it randomly fail in Production or during an important presentation? Also race conditions generally are way harder to figure out and fix that the more "reliable" kind of bug.
20ReplyOr it was an issue with code generation, or something in the environment changed.
1Reply
Good luck figuring out why it sometimes doesn't work 🙃
9ReplyMmm, race conditions, just like mama used to make.
8ReplyThere was that kind of bug in Linux and a person restarted it idk how much (iirc around 2k times) just to debug it.
7ReplyThis is 100% valid when dealing with code generation sometimes and I hate it
6ReplyLegit happens without a race condition if you’ve improperly linked libraries that need to be built in a specific order. I’ve seen more than one solution that needed to be run multiple times, or built project by project, in order to work.
2ReplyIsn't that the definition of a race condition, though? In this case, the builds are racing and your success is tied to the builds happening to happen at the right times.
Or do you mean "builds 1 and 2 kick off at the same time, but build 1 fails unless build 2 is done. If you run it twice, build 2 does "no change" and you're fine"?
Then that's legit.
2Reply
This is why debugging race conditions is the absolute worst.
1Reply
The first is a surprise; the second is testing.
41Replycould be a race condition
35ReplyHmm..you may be right. I'll get my Hispanic friend to run it and see if he gets the same result.
66ReplyIt works on my machine
21Reply
i sometimes do that so i can inspect the error messages on a cleared terminal
28ReplySometimes I forget what I was looking for and have to restart the mental loop when doing this.
9Reply
One of my old programs produces a broken build unless you then compile it again.
23ReplySome code has bugs.
Some code has ghosts.
3Reply
Just had that happen to me today. Setup logging statements and reran the job, and it ran successfully.
22ReplyI've had that happen, the logging statements stopped a race condition. After I removed them it came back...
18ReplyThank you for playing Wing Commander!
11Reply
======== 37/37 tests passing ========
21ReplyThat's when the real debug session begins
11ReplyGreat time to find out your tests are useless!
10ReplyThey’re not completely useless. They’re conditionally useless, and we don’t know the condition yet.
4ReplySo how do you write a good test? It's like you have to account for unknown unknowns, and I don't really have a good theory for doing that.
Right now, I usually end up writing tests after the code is broken, and most of them pass because they make the same mistakes as my original code.
1Reply
If that doesn't work, sometimes your computer just needs a rest. Take the rest of the day off and try it again tomorrow.
19ReplyThe crazy thing is that sometimes this just works...
19ReplyI often do this, but I always hit Ctrl-S before running it again. Shamefully, this probably works about 10% of the time. Does that technically count as changing nothing?
18ReplyThat and a make clean can work wonders.
12ReplyAutosave on focus loss dude.
3Reply
Well, duh! You need to use the right incantations!
16ReplyAll praise the Omnissiah, so on, and so forth.
9ReplySomething something motive force.
4Reply
I actually did this earlier today
15ReplyI've only recently joined the dev world and I saw this post in the morning. Late this afternoon I'm doing a deployment that fails, couldn't determine the cause as I'm a noob, before bothering a more senior dev for help I run it again... It worked.
1Reply
Somehow higher than 0% success rate.
11Replyit's only dumb til it works
10ReplyPermanently Deleted
7ReplyGot to make sure it's not one of those phantom failures.
5ReplyThe definition of insanity is doing the same thing over and over and expecting different results.
5ReplySponsored by QA gang. Gotta make sure it's a 5/5 issue and not just a frequent issue
5ReplyMy way: wrap it in a shell script and put a condition if exit status is not 0 then say "try clear the cache and run it again"
4ReplyAKA - the test suites at half the companies I've worked. Except they use a loop with retries as well
1Reply
Einstein did say...
3ReplyEver work?
2ReplyDisturbingly, yes
11ReplyEvery sufficiently complicated system is indistinguishable from being alive, and living beings need some warm-up time.
1Reply
All the time. Causes include:
- Test depends on an external system (database, package manager)
- Race conditions
- Failing the test cleared bad state (test expects test data not to be in the system and clears it when it exits)
- Failing test set up unknown prerequisite (Build 2 tests depends on changes in Build 1 but build system built them out of order)
- External forces messing with the test runner (test machine going to sleep or running out of resources)
We call those "flaky tests" and only fail a build if a given test cannot pass after 2 retries. (We also flag the test runs for manual review)
7ReplyI mean
maybe
4ReplyNot with code, but i write a lot of LaTeX and that often starts working on second compilation
1Reply
If that doesn’t work, restart it and then try.
1ReplyInsanity is doing the same thing over and over again and expecting different results.
1ReplyWell if it doesn't work once try again if it doesn't work twice or thrice maybe there's a problem. If it works it is resolved ... for now, least effort solution.
1ReplyI only do it because it works!
1Replyon xcode i would say it has a 50% chance of working
1Reply