I've liked this post for a long time. It articulates a way of growing in this field that I haven't seen in a lot of places. Whenever I've posted it in a slack or similar it seems pretty divisive - some people don't seem to like it.

What don't they like about it?

I’ve heard that it’s depressing! Hard for me to get that one.

It is a pedagogically useful exercise to spent some time trying to figure out what went wrong before firing up the debugger or writing new test cases. One approach is to try to identify the assumptions, and especially the tacit ones, that would have to be true for the code to work, and which might, if false, lead to the specific error observed.

While I think it is wise to heed the warning implicit in Kernighan's aphorism, the question it poses can be answered by noting that finding errors provides additional information, allowing you to debug it without first getting any more clever. What makes debugging harder than writing is that in the former, you are dealing with reality, not your simplified, incomplete and possibly tacit assumptions about it.

I often think of it almost exactly backwards from that: "What it's doing should be impossible. So what precursor that I think is impossible would have to be possible for that to fail?" I often come up with two or three possibilities. And then: "How can I find out which one it is?" This often involves re-running it with enhanced logging.

And then repeat, with the new thing that should be impossible but is still happening, until I get to the root cause.

We frequently see what we expect to see. If I'm convinced something isn't in a certain location, I won't find it, digital or analog.

> 'I feel that there's a bug in this specific bit of code.'

The precise feeling I try to avoid leading PR reviewers into.