The Best Programming Advice I Ever Got

A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

http://www.informit.com/articles/article.aspx?p=1941206

Ken had the "luxury" of working with simple systems
where kilobytes were a hot commodity and code
complexity was really limited by hardware.
I wonder how he would debug something more complex/modern
with his mental models.
I'd rather spend my mental resources reading
stack traces and debugging manually.

>>2
No, Rob was distracted by the minutiae of trying to hit upon the exact runtime state to blame, which slowed him down. Ken was in direct analysis mode.

The amount and structural complexity of code that you personally write hasn't changed since them. If anything, complexity of the specifics of what you're writing has gone down since the days of juggling machine code.