I Don't Understand This (Yet)

This is why it is relatively easy to work on a project you were in on from the beginning.

and why it is always a struggle to come into a project with an existing codebase.

I've spent many years working on large existing codebases and it gets in the way of liking your job.

For some reason, not being on the keyboard or operating tools seems to free up a lot of mental bandwidth.

Nothing gets done without someone being hands-on though so arguably yes, that role is more important. If there's just 1 person they usually have to stop and think really hard periodically and keep very good notes to avoid getting lost in the weeds.

Sitting and thinking on the other hand, is best for dealing with errors in your own thinking. Ideally, we should have a well-thought-out argument for why something will work, so when it doesn't, our argument needs to be refined.

Even if thinking has not solved the problem, it may help you find where to look next.

One tip I have is that even if you wrote the code and think you know how it works, stepping through it in your mind might lead you to see where you are making a questionable assumption.

You may think that you can do that just as well in the debugger, and you may be right, but there are two ways of using the debugger: one is to hit 'step' and see what happens; the other is to figure out what you expect will happen, and then check if your expectation was correct. There have been many times when I have stepped up to the point where the bug is about to happen, and then realized what is wrong before taking that final step.

[1] I myself don't use a debugger much; I'm frequently working on something distributed where a debugger is laughably useless.

You already have a more narrow sense of the problem space, else you wouldn't know where to look with the debugger either...

BUT. Where I think the OP is right is what you do with the debugger. I agree with OP that you shouldn't use the debugger just for generalized "seeing what is going on" or jump too quickly into "finding the problem".

You should be using it to prove or disprove a hypothesis. Initially, hypotheses about your mental model, not about the problem itself.

But you can and often need to use the debugger in order to build the mental model.

The next part of quote from OP is:

> What Ken was doing was constructing a mental model of the program. When something broke it was an error in that model. He'd think of how that error might happen or where the code might not satisfy the model.

You absolutely can and I'd go so far as to say even should use the debugger as an aid to building the mental model. If you're not Ken Thompson, and depending on how familiar you are with the code, and the nature of the platform and codebase, it isn't necessarily useful to just be totally inside your head trying to "build the mental model" and think of what might be breaking it.

So it's not really about how quickly you pull out the debugger. But it is absolutely good advice not to immediately start debugging ("find the problem") with it, and not to just use the debugger aimlessly, but to start with a separate "mental model phase".

I see why the OP wants to tell you not to use the debugger in this phase, to help you understand it is in fact a separate phase, and because the debugger can lead you to miss the forest for the leaf. But you can and probably often should use the debugger there too, I agree. But you use it to build your mental model -- if you aren't sure you have a mental model, make some guesses (about how the code works, NOT about "what's wrong"), then use the debugger to confirm or deny them. To figure out "how does this code work, big picture" before trying to use it to figure out "why is it broken".

IF you are pretty familiar with the particular platform and codebase, AND pretty experienced with doing this kind of work, you might not find the debugger helpful for that first phase, like Ken Thomson. But i'd argue it's also fine to use the debugger there, it's a question of what you are using it to do.

My debugging goes like this:

1) I need to have a model in my head of what I think is going on even if simple.

2) I make a change X with the idea that result Y should happen. VERIFYING THIS HYPOTHESIS IS VITALLY IMPORTANT. Your change should create cause and effect.

3) I test that result Y actually happened--generally this is where I'm using the debugger.

4a) If result Y happened and result Y means my program is fixed, congratulations, you are done.

4b) If result Y happened but my program is not yet fixed, go back to make another hypothesis and go back to step 2.

4c) If result Y did not happen, undo change X, update your mental model and go back to step 1. This is where the "think hard" part mostly comes in.

The toughest bugs are the ones that require you to update your mental model the most.

One more approach that worked several times for me is to start writing a Stackoverflow question, carefully formulating the problem for the reader who does not have your context. Often I saw the answer before you finish writing, and never posted the question.