Most of the time analysis paralysis is a signal that you lack sufficient understanding of the needs to actually write the right code. There are two ways to break out of it: (1) understand the problem better, and (2) build something, anything, see why it wouldn't work, and then go back to the drawing board.
> 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.
I've found the opposite. Maybe "Ken" could do it, but most programmers who think they can can't. I've had three programmers spend three days thinking about a problem to no avail, and then fired up a debugger and tracked it down in half an hour. Never be too proud to use your tools.
This was my first thought, as well. It's hard to think when you're staring at the blinking cursor. Spending a little bit of time with a pen and a napkin works wonders for design and reduces the number of times you'll have to hack in fixes for cases you didn't consider.
I agree. While still learning to code, I discovered this aphorism myself when the thought dawned on me that contrary to my previous practice, the programmer thinks for the computer and not the the other way round.
It's stood the test of time, I've passed it on to many juniors.