Valid. You need to know if it’s a sometimes bug or an always bug.

Happy debugging if it works on the second try... 😬

Ofcourse. The first stage is denial.

Very true, especially when working with recursion. (Debugging recursion sucks)

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.

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.

tilts tin foil hat to the left...

Works now 👍

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.

But sometimes it works the second time because it loaded something in the bg.

You'd be surprised at how many times this would help. Sometimes data could be in garbage state and would change between execution.

Actually valid approach. Could be a race condition

My code works

Let's change something and run it again

Well yes, the trick is to attach the debugger for the second run.

xkcd 242 obviously

You make a change. It doesn't fix it.

You change it back. The code now works.

The usual for me is that I flip back over to my editor and hit ctrl+save, cause heaven forbid I ever remember to do that before running.

Trying to debug race conditions be like

The first one is to warm up the engine. Like getting your car ignition to kick over in the winter

Code doesn't work; don't know why.

Code works; don't know why.

The absolute worst thing that can happen is if it suddenly starts working without doing anything

The error message goes stale when it's been sitting for a while. I need to see a fresh one.

You know, youve gotta give your computer some warmup.

Ah, come on this is valid investigation.

If you get the same error every time, you know you can find it and debug it, somewhat with ease.

If you don’t, you might have a thornier issue at hand.

You jest but “wait and retry” is such a powerful tool in my DevOps toolbox. First thing I tell junior engineers when they run across anything weird

This would be more mockable if it didn't often WORK.

Not sure which is worse. When you know you changed nothing and it inexplicably starts|stops working compared to yesterday

Running the code again is fast and requires no thinking. Finding the problem is slow and requires a lot of thinking.

It's worth looking under the light-post in case your keys somehow rolled there. Just not for long.

gotta rule out cosimc rays flipping a bit or two

I started coding professionally using Visual Basic (3!). Everybody made fun of VB's On Error Resume Next "solution" to error handling, which basically said if something goes wrong just move on to the next line of code. But apparently nobody knew about On Error Resume, which basically said if something goes wrong just execute the offending line again. This would of course manifest itself as a locked app and usually a rapidly-expanding memory footprint until the computer crashed. Basically the automated version of this meme.

BTW just to defend VB a little bit, you didn't actually have to use On Error Resume Next, you could do On Error Goto errorHandler and then put the errorHandler label at the bottom of your routine (after an Exit Sub) and do actual structured error handling. Not that anybody in the VB world ever actually did this.

Just making sure that the write buffer was flushed on time or something.

sometimes it needs to warm up.. or cool down

When your Makefile is so fucked up that you have to run it multiple times to get everything to build and link properly.

Computer needs practice to get program right.

And run it with the debugger.

This is just how you use Visual Studio

Because you're Good developer

... try it now.

sometimes you don't compile it enthusiastically enough

demons ahem. data-races.

does it count if i run it again, but with a debugger attached?

This genuinely happens regularly in our testing environment 🥲

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

Most applications aren't written to compile deterministically so there is always a chance.