[arghwhat]

For web, my favorite is JIT miscompilations. A tie between a mobile Safari bug that caused basic math operations to return 0 regardless of input values (basic, positive Numbers, no shenanigans), or a mobile Samsung browser bug where concatenating a specific single-character string with another single-character string would yield a Number.

Debugging errors in JS crypto and compression implementations that only occur at random, after at least some ten thousand iterations, on a mobile browser back when those were awful, and only if the debugger is closed/detached as opening it disabled the JIT was not fun.

It taught me to go into debugging with no assumptions about what can and cannot be to blame, which has been very useful later in even trickier scenarios.

[hinkley]

I think you might use “favorite” the way I mean “fun” (if I say fun at work, it’s because we are having none)

A lot of my opinions on code and the human brain started in college. My roommate was washing out and didn’t know it yet. The rules about helping other people were very clear, I was a boy scout but also grade-a bargainer and rationalized so I created a protocol for helping him without getting us expelled. Other kids in the lab started using me the same way.

There were so many people who couldn’t grasp that your code can have three bugs at once, and fixing one won’t make your code behave. Some of those must have washed out too.

But applying the scientific method as you say above is something that I came to later and it’s how I mentor people. If all of your assumptions say the answer should be 3 but it’s 4, or “4” or “Spain”, one of your assumptions is wrong and you need to test them. Odds of being the flaw / difficulty of rechecking. Prioritize and work the problem.

(Hidden variable: how embarrassed you’ll be if this turns out to be the problem)

[giancarlostoro]

There's a weird one I ran into, and I for the life of me do not remember which project it was under, but if I open dev tools, the style changes for an element, then if I close dev tools, the style goes back to normal. I never could figure out what the heck is going on. I almost want to blame the viewport size changing just slightly, but I couldn't find a single CSS rule that would make it make sense, and I think even popping it out, it behaved exactly the same. It was frustrating, but I felt like I had to ignore it since no normal user would ever see it, it just made debugging with dev tools confusing.

Edit: In your case, that's where I start print debugging LOL

[bch]

This reminds me of finding out (the Hard Way) that Perl’s sort used internally[0] the same $a or $b that I happened to be using.

[0] https://perldoc.perl.org/functions/sort

If the subroutine's prototype is ($$), the elements to be compared are passed by reference in @_, as for a normal subroutine. This is slower than unprototyped subroutines, where the elements to be compared are passed into the subroutine as the package global variables $a and $b (see example below).

[hinkley]

println(“1”);

…

println(“2”);

…

println(“wtf”);