[breatheoften]

What reason is there to think “Imagining how your code works” should always be faster than “seeing how your code works”? It is certainly the case that sometimes one of these is faster than the other but it’s gonna be codebase, tooling, and scenario dependent which one actually is faster.

[hzhou321]

Did I say "always"? If I did, that is not the point.

[breatheoften]

I’m trying to think through why removing the debugger should help one build a mental model of the code faster than having constant access to one.

I guess I can imagine workflows that are overly debugger dependent - the programmer has a “trust nothing” mentality and checks the behavior of the code against their mental model of the code “too much” thus slowing them down.

But I think theres reason to think the programmer can maintain a mental model of the program while using debugger queries to verify aspects of that model in a way that’s a lot more efficient than relying on mental model alone. Beyond that at some point observation of the behavior of the program will come into play — and I don’t see why utilizing the power of a debugger to generate a lot of precise observations quickly isn’t a pure win ...

[hzhou321]

Seems that you are agreeing with imagining and use debugger to verify is a lot more efficient. And for verification, print is more direct than orchestrating the breakpoints and then print with debugger's syntax (or gui navigation).