I've observed this as well, and I think both models are valid. Sometimes banging out code non-stop is where it's at. And sometimes resting and letting the solutions bubble up into your consciousness is where it's at.

Here's my theory on when they both apply, based on my experience: When you're in a problem domain that you've mastered thoroughly, then writing code non-stop is where it's at. When you're in a problem domain that you're newer to and haven't mastered as thoroughly, then you're going to be banging your head against the wall more often and find your solutions more often while resting.

This is the big difference between "research" and "development". If it's a research project, you don't really know what you're doing, or how to do it, so there is much uncertainty. If it's a pure development project, you pretty much know what to do and you go bang it out.

I started contemplating this a lot because for about 20 years, I did business software-- ERP systems-- inventory control, order management, that sort of thing. I had been doing it so long that every problem that came up, I pretty much knew exactly how I was going to architect the data, everything just instantly crystallized in my mind once I'd talked with the stakeholders about what kinds of problems we needed to solve. I could estimate development timeframes astonishingly well.

Then I moved into game development a few years ago, and suddenly my ability to estimate went into the toilet. I started finding that trying to code 15 hours a day wasn't as effective as it once was. I spent a lot of time being stuck with problems.

Finally I realized that the reason I was so radically productive and good at estimating things wasn't because I'm a natural programming badass. It was because I had 10+ years of experience doing the exact kind of things I was doing, and developed all kinds of experience, intuition, and tools to rock the house. Once I changed problem domains and languages and lost my old bags of tricks, the entire landscape changed.

So I agree with you that sometimes it's all about banging out a ton of code, and sometimes it's more about relaxing and meditating. Most developers today-- if they're not going obsolete-- are radically changing technology landscapes every few years. Or should be.

My interpretation of that rule. I think the author is only asking readers not to goof off or postpone work that can be right away. Like mentioned very often, getting into the right context for a task takes some time. So working till 8.15PM instead of leaving at 8.00PM, but completing the task at hand is better than having to come an hour early the next day. I find that even very incomplete insignificant tasks keeps nagging away in your head until you actually get around to do it.

You're spot on. Archimedes said he could move the world with the right lever. Figuring out the right "angle" or abstraction for a task reduces the effort required and often reduces the complexity of the solution, and that happens more often "offline" for me than it does while staring at the code / problem.