No, the bug is in your code (and mine)

It’s entirely possible that I’ve posted something on this topic before. I know I’ve posted about it on social media before.

The last of these is at least phrased as a question, but usually the surrounding text makes it clear that the poster expects that the answer is “yes, it’s a bug in the compiler.”

Sometimes, the bug really is in the library you’re using, or in the JIT compiler, or the C# or Java compiler, or whatever. I’ve reported plenty of bugs myself, including some fun ones I’ve written about previously to do with camera firmware or a unit test that only failed on Linux. But I try to stay in the following mindset:

So my first steps when diagnosing a problem are always to try to make sure I can actually reproduce the problem reliably, then reproduce it easily (e.g. without having to launch a mobile app or run unit tests on CI), then reproduce it briefly (with as little code as possible). If the problem is in my code, these steps help me find it. If the problem is genuinely in the compiler/library/framework then by the time I’ve taken all those steps, I’m in a much better place to report it.

But hold on: just because I’ve managed to create a minimal way of reproducing the problem doesn’t mean I’ve definitely found a bug. The fault still probably lies with me. At this point, the bug isn’t likely to be in my code in the most common sense (at least for me) of “I meant to do X, but my code clearly does Y.” Instead, it’s more likely that the library I’m using behaves differently to my expectations by design, or the language I’m using doesn’t work the way I expect, even though the compiler’s behaving as specified1.

Leave a Comment