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 t

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.