Cutting edge debugging

One of the great pleasures of advancing in one’s craft is the thrill of solving newer, more difficult problems. In the course of my work, I frequently encounter many bugs which appear at first glance to be impossible. Not just impossible to solve, but intrinsically impossible. It’s as if being at the very frontiers of technology exposes one to strange new logics that the human mind is not fit to grasp.

Each of these bugs is, of course, unique, and it would be folly to suggest that there could be any sort of systematic method that could be applied at the cutting edge of technology, as if one could push back the boundaries of ignorance in much the same way as one fills in a tax return. Nevertheless, the following principles have served me pretty well, and perhaps deserve a wider audience.

• You’re editing the wrong file
• You’re editing the right file, but on the wrong machine
• You’re editing the right file, but you forgot to save it
• You’ve edited the right file, but you forgot to recompile
• The thing you thought you turned on, you actually turned off
• The thing you thought you turned off, you actually turned on
• You’re in a meeting, and you should be paying attention. They wouldn’t have eighteen people talking about it unless it was really important, would they?
• You’re running the wrong version
• You’re running the right version, but on the wrong machine
• You’ve fixed the problem, but forgot to push
• You’ve fixed the problem and remembered to push, but you forgot to commit
• You’ve fixed the problem, committed, and pushed. However, many users were relying on the previous, broken behaviour and so now you must roll back.

I offer up these principles humbly: no single approach can suffice at the very fringes of the known. I earnestly hope that by meditating on them we can achieve things as yet undreamt of.