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

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

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)

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.

Sometimes, this actually works simply because of your compiler lagged the previous time.

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.

My code works

Let's change something and run it again

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

Actually valid approach. Could be a race condition