And the worst part is when it actually does and you have no fucking idea what went wrong before.
112 0 ReplyThe pc had the hiccups and now it's fine. Problem solved!
30 0 ReplySome times my game engine needs a wake up run, then an actual run.
8 0 ReplyIt works on my machine!
1 0 Reply
Blame cosmic rays.
1 0 Reply
That's step zero: rule out black magic
105 0 ReplyThose damn cosmic rays flipping my bits
59 0 ReplyPlease tell me you look skyward, shake your fist and yell damn you!!!!
9 0 ReplyI wonder if there's an available OS that parity checks every operation, analogous to what's planned for Quantum computers.
5 0 Reply
That feeling when it is, in fact, computer ghosts.
15 0 Reply
Me: "Hmm... No... No the code is good, it's the compiler that's wrong."
runs again
72 1 ReplyNo 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.
38 0 ReplyIt'll be done soon, then I can go home. TGIF, am I right?
12 0 Reply
Yeah, but sometimes it works.
61 0 ReplyIt'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.
20 0 ReplyOr it was an issue with code generation, or something in the environment changed.
1 0 Reply
Good luck figuring out why it sometimes doesn't work 🙃
9 0 ReplyMmm, race conditions, just like mama used to make.
9 0 ReplyThere was that kind of bug in Linux and a person restarted it idk how much (iirc around 2k times) just to debug it.
7 0 ReplyThis is 100% valid when dealing with code generation sometimes and I hate it
6 0 ReplyThis is why debugging race conditions is the absolute worst.
1 0 ReplyLegit 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.
1 0 ReplyIsn'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.
2 0 Reply
We call this sort of test "fuzzy". If it's really bad they call it by my own personal identifier of "unstable".
1 0 Reply
The first is a surprise; the second is testing.
45 0 Replycould be a race condition
35 0 ReplyHmm..you may be right. I'll get my Hispanic friend to run it and see if he gets the same result.
68 0 ReplyIt works on my machine
22 0 Reply
i sometimes do that so i can inspect the error messages on a cleared terminal
28 0 ReplySometimes I forget what I was looking for and have to restart the mental loop when doing this.
9 0 Reply
One of my old programs produces a broken build unless you then compile it again.
25 0 ReplySome code has bugs.
Some code has ghosts.
3 0 Reply
Just had that happen to me today. Setup logging statements and reran the job, and it ran successfully.
24 0 ReplyI've had that happen, the logging statements stopped a race condition. After I removed them it came back...
20 0 ReplyThank you for playing Wing Commander!
11 0 Reply
======== 37/37 tests passing ========
22 0 ReplyThat's when the real debug session begins
12 0 ReplyGreat time to find out your tests are useless!
11 0 ReplyThey’re not completely useless. They’re conditionally useless, and we don’t know the condition yet.
4 0 ReplySo 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.
1 0 Reply
The crazy thing is that sometimes this just works...
19 0 ReplyIf that doesn't work, sometimes your computer just needs a rest. Take the rest of the day off and try it again tomorrow.
19 0 ReplyI 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?
18 0 ReplyThat and a make clean can work wonders.
12 0 ReplyAutosave on focus loss dude.
4 0 Reply
Well, duh! You need to use the right incantations!
17 0 ReplyAll praise the Omnissiah, so on, and so forth.
10 0 ReplySomething something motive force.
4 0 Reply
I actually did this earlier today
15 0 ReplyI'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.
1 0 Reply
Somehow higher than 0% success rate.
14 0 Replyit's only dumb til it works
10 0 ReplyPermanently Deleted
7 0 ReplyGot to make sure it's not one of those phantom failures.
5 0 ReplyThe definition of insanity is doing the same thing over and over and expecting different results.
5 0 ReplySponsored by QA gang. Gotta make sure it's a 5/5 issue and not just a frequent issue
5 0 Reply"Works in my environment."
4 0 ReplyMy 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"
4 0 ReplyAKA - the test suites at half the companies I've worked. Except they use a loop with retries as well
1 0 Reply
Einstein did say...
3 0 ReplyEver work?
2 0 ReplyDisturbingly, yes
11 0 ReplyEvery sufficiently complicated system is indistinguishable from being alive, and living beings need some warm-up time.
1 0 Reply
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)
7 0 ReplyI mean
maybe
4 0 ReplyNot with code, but i write a lot of LaTeX and that often starts working on second compilation
1 0 Reply
Insanity is doing the same thing over and over again and expecting different results.
1 0 ReplyI only do it because it works!
1 0 ReplyIf that doesn’t work, restart it and then try.
1 0 ReplyWell 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.
1 0 Replyon xcode i would say it has a 50% chance of working
1 0 Reply