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.

Every so often - thankfully not too often - I see a post on Stack Overflow containing something like this:

• This looks like a bug in VS.NET"
• I'm 100% sure my code is correct"
• This seems like a glaring bug."
• Is this a bug in the compiler?"

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:

When my code doesn't behave how I expect it to, my first assumption is that I've gone wrong somewhere.

Usually, that assumption is correct.

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 specified¹.

So the next thing I do is consult the documentation: if I've managed to isolate it to a single method not behaving as expected, I'll read the whole documentation for that method multiple times, making sure there isn't some extra note or disclaimer that explains what I'm seeing. I'll look for points of ambiguity where I've made assumptions. If it's a compiler not behaving as expected, I'll try to isolate the one specific line or expression that confounds my expectation, dig out the specification and look at every nook and cranny. I may well take notes during this stage, if there's more to it than can easily fit in my head at one time.

At this point, if I still don't understand the behaviour I'm seeing, it may genuinely be a bug in someone else's code. But at this point, I've not only got a minimal example to post, but I've also got a rationale for why I believe the code should behave differently. Then, and only then, I feel ready to report a bug - and I can do so in a way which makes the maintainer's job as easy as possible.

But most of the time, it doesn't end up that way - because most of the time, the bug is in my code, or at least in my understanding. The mindset of expecting that the bug is in my code usually helps me find that bug much more quickly than if my expectation is a compiler bug.

There's one remaining problem: communicating that message without sounding patronising. If I tell someone that the bug is probably in their code, I'm aware it sounds like I'm saying that because I think I'm a better at writing code than they are. That's not it at all - if I see unexpected behaviour, that's probably a bug in my code. That's one of the reasons for writing this post: I'm hoping that by linking to this in Stack Overflow comments, I'll be able to convey the message a little more positively.

¹ This still absolutely happens with C# - and I've stopped feeling bad about it. I convene the ECMA task group for standardizing C#. This includes folks whose knowledge of C# goes way deeper than mine, including Mads Torgersen, Eric Lippert, Neal Gafter and Bill Wagner. Even so, in many of our monthly meetings, we find some behaviour that surprises one or all of us. Or we just can't agree on what the standard says the compiler should be doing, even with the standard right in front of us. It's simultaneously humbling, exhilarating and hilarious.