Don't argue with the compiler September 23, 2025

One of the lessons I learned from both martial arts and software development is to find solutions within myself rather than wasting time blaming someone else for my problems.

When practicing a defense against a punch, if I'm hit, the defense didn't work. Simply put, that's all there is to it. Beginners sometimes complain, “But I did everything right!” They usually didn't; otherwise, the defense would have worked. Sometimes, they start blaming their partner – or even the floor (“The edge of the mat was sticking up!”). However, this misses the point. If I'm hit, I'm hit. And that's my problem to solve.

Sometimes, I practice with one partner and my take-down is working really well, and then we switch partners, and suddenly I am hit every time. The temptation to blame the new partner can be really great. After all, it worked before, right? Why did the new partner attack differently? Shouldn't they do it like the first one? I have learned to resist this line of thinking and to focus on what I need to change to cope with the way the new partner is attacking.

By now, I am an instructor myself, and there is a demonstration I like to give when I detect this spirit creeping into the training. I call out someone and tell them to punch me. Then, while they are getting ready, I say, “Ah, no, we'll do it differently. Lie down on the mat, please.” Given the situation (I'm the instructor; I'm clearly trying to demonstrate something; I'm asking nicely), they always do. Then I say something like, “If the attack comes like this, you don't need the technique.” Silence. And usually embarrassment on the part of the person lying on the ground. “Don't get me wrong – cooperation is good! We need to cooperate when we are training. And thank you for not hitting me! But if we want to practice a defense against a punch to the chin, we need a punch to the chin, not a partner lying down, not a partner holding their hand in front of my face, not a partner punching to the side.”

This demonstration only works because in this situation the person doesn't really mean to attack me. An attack is something I don't control. If the other guy does exactly what I want, that's not an attack. And if I can talk them into changing their punch to make it easier for me, well, that's not an attack either. I have to deal with the attack the way my opponent delivers it. And if I'm hit, it is I who needs to change something.

In software development, there is a very similar situation. If the compiler throws an error, my code doesn't work.^[1] Beginners sometimes complain, “But I did everything right!” They usually didn't; otherwise the code would have compiled. Sometimes, they start blaming the compiler (“It must be right! Why does the stupid compiler keep complaining!?”). However, this misses the point. If it doesn't compile, it doesn't compile. And that's my problem to solve.

Situations like this occur again and again. I'm sure everyone who has been programming for any length of time will recognize it. Why, just this week I had a problem compiling a Java program which used a third party library. The compiler complained that it couldn't find the class from the library I needed. For a second, I thought, “It must work! I did everything right!” But only for a second. Then I looked at my own changes again, and lo and behold! I had messed up the dependency declaration.^[2] I fixed it, and it worked.

Arguing with the compiler is a waste of time – as is arguing with my opponent.^[3] If I get an error, or if I get hit, I use this as feedback to fix my code or my defense.

Yes, compiler bugs do exist – but unless you are a compiler developer or using some niche language with only a handful of users, they are rare. In 30 years of software development, I've had a production problem due to a compiler bug exactly once, about 15 years ago. (It was a C program, and the bug only appeared with compiler optimization turned on, i.e., in production builds.) In all other cases, the problem was in my own code so diverting my energy to searching somewhere else would just slow me down. And even in the case that the problem really is elsewhere, rigorously validating my own code and thinking enables me to better diagnose the issue, which helps, e.g., when submitting bug reports. So, even though sometimes, very rarely, it is the compiler that's wrong, I always look at my own code first. And second. And third.

Likewise, in martial arts training, the attacker sometimes really is wrong. Defense techniques are highly situational, and if your training partner has not been paying attention, they may inadvertently change the situation enough for the defense not to work as shown. A good instructor will notice this and correct the form of the attack – and also explain the situation and show what you would need to change to deal with the other form. This is part of the instructor's job. As a defender, you should not try to correct your partner but instead focus on your own form and improve your capacity for dealing with attacks as they come. Arguing with your partner does not lead to progress.

So this is what I learned: To make progress, when I encounter a difficult situation, I look to myself and don't blame the other party, be it a compiler or a training partner. I treat the difficulty as feedback and use it to improve my own game. There is the odd exception, but looking for that shouldn't be my first reaction. Not even the second. By focusing on my part, I make progress much faster.