Execution time usually isn't thinking time.

Some advice that makes sense to me: Take time to think, and to design.

I struggle tremendously to do that - it always feels like my design-time happens in a vacuum. The output feels useless b/c I didn't represent the reality/constraints while designing, so when I sit down to execute, getting from now to the plan just doesn't make any sense. At execution time, shortcuts and quick wins are much more obvious, and progress goes in a different direction. What was the point of designing?

So here's another idea - improve review processes.

It's easy to read code you wrote - well, it's not easy to sit down and do anything, but the success rate is very high once you've started (vs. execution, when you might try to execute for a while and throw it away). Review time is always useful - you're familiarizing and gathering data from past executions and designs.

It's really about creating and collecting aha moments - insights that bubble up and spark at odd hours, as your understanding of the problem deepens.

Review and take notes, execute and take notes. Sure, plan and design if you want to do that explicitly - really it happens _all_ the time, and the act of planning/designing is when you write down the insights and constraints, and put all the captured parts of the problem together.

Fine, that's planning - for some reason I'm quite put off by it!