This is exactly what I learned after years of developing around meetings. Block your time first. And block your time based on your tasks you have to complete.

Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method.

I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"

I can't do anything with some complexity in one hour increments. I need days (or weeks) to immerse myself into the issue to develop a mental model. In my view working in short increments leads to very superficial work.

I think I know what parent is getting at. I am increasingly able to bypass the "load problem into brain" stage by reducing the problem scope to a subset. When the problem seems potentially quite large, like "greenfield a new system", I look for "seven plus/minus two coherent concepts": while I can't know the whole scope until development begins, I can pick a set of concepts that I can commit to memory(hence, about 7) and search for an optimization of which concepts I'm using that makes each one cohere better with the others, contingent on whatever belief is driving the need for a software solution.

This process typically only takes a few hours at most and usually illuminates something really unexpected about the problem space. Selecting for coherence is effective at reducing problem scope since it cuts through unquestioned practices: in a more coherent solution all the answers feed into each other.

In my previous methods I would just sit and stare at the problem and sit and stare at techniques until a match of technique to problem came to mind. That's why it took so long - there wasn't a philosophy there, so my thinking could drift in an undirected way for long periods and even get deep into writing code without doing anything effective.