>Rob Pike of golang fame noted that while he reached for the debugger first thing, Ken Thompson would ignore what Rob was doing and just stand and think. Then after a while he'd say: "I know what's wrong" and very often be right.

I feel like this is not a helpful take on debugging for most of us. I'm certainly not as good at this as Ken Thompson, and very seldom is the problem space simple enough that I can hold a complete mental model of it in my head. Instead I reach for the debugger to collect more data on what's going on. And I can usually find the issue by looking a lot faster than I can correctly theorize about it.

In Debugging by Davig J. Agans, his third rule is "Quit thinking and look". And I tend to agree. In the majority of cases when I'm debugging a problem the solution only reveals itself when I see that missing piece of information.

EDIT: As others have rightly pointed out, if I wrote the code I've already thought about it and have a mental model of what I wrote. And yes, I do think about what could be causing the problem. I guess it's those cases where I think it should be working in a certain way, but it isn't, where I find it most valuable to stop thinking and look. And usually in those cases I either have an incorrect or incomplete model, or I wrote something that didn't match what I was thinking.

This is good stuff. I'd add: if you're tussling with what seems to be a very confusing problem, often you are looking at _two_ problems.

> Use the debugger sparingly if at all. See if you can use more exotic ways like printfs, dump out data via files, assertions etc just for the sake of getting a wider range of troubleshooting techniques should you find yourself without a debugger someday

Often it's the reverse: printfs, data file dumping, etc. are impossible, but the debugger is always there. If you find yourself chasing a bug into glibc or Rust stdlib, printf debugging won't be sufficient. Using a debugger is an underrated skill.

> ...The diffuse mode shuts down when we're stressed. There's no time for dreamy big picture thinking during crunch time...

I'd add also that the focused mode often gets you stuck even more under stress. Both approaches are complimentary. This kind of problem solving needs thinking pace, just as if mind were a CPU with a program being weaved in real time, morphing constantly, seeking patterns, eliminating choices.

- Hey, Jim, are you sleeping at your desk? - No, Mr. Stone, my mind is thinking! Just be patient and please don't interrupt...

On a serious note, under the stress or not, it's important to recognize when one's own mind got stuck. Getting other people involved (as listeners or active participants) is often the only way to get through without exhausting oneself. I wish this was more encouraged in teams, instead of my task must do kind of approach.

Talk to someone. Tell them about the problem. Show them your previous steps trying to figure it out. Talk about possible solution you've thought of. Share your frustration. Ask them if they have any ideas.

When you are done you would have come up with at least one new thing to try.

That coin problem is fun. I’m not really familiar with insight problems like this, so it took about a minute to get it.