The approach that always works for me is iteration and recursion. Just like drawing, where you do a loose sketch and refine it until you're happy. You're either stepping back and work on the whole, or focus on a small part to detail it[0].
So for a software project, I break it into parts recursively. Sometimes for a module, I can build some scaffolding even when I'm not sure about the full implementation. I can go up and down that tree of problems and I always have something to break away from my current thinking track. So there's always a lot of placeholder code, stubs, and various TODO comments around my codebase. And I rely heavily on refactoring (which is why I learned Vim, then Emacs as they helped me with the kind of quick navigation I need for that approach). Also REPL and/or some test frameworks.
I do something similar, and that is likely one of the ways for your subconscious to engage with the material.
However I’ve noticed that too much refactoring while exploring the problem space becomes tedious for me. At that point I go back to a notepad or whiteboard. Maybe this change of medium is another way to engage the subconscious?
And to your point about vim/emacs - the choice of tools no doubt impacts your engagement with the problem at hand. That’s why having AI generate teams of code doesn’t work for me - but using it to iteratively develop some PoC code whose core I then incorporate into my own code works brilliantly.
> However I’ve noticed that too much refactoring while exploring the problem space becomes tedious for me. At that point I go back to a notepad or whiteboard.
Yes, I'm only writing code when I got a good idea on what I want to write. Most of the times, I'm doing research or doodling design ideas. Refactoring is when I've thought of a better approach for something. It's almost always easy to do as big refactoring only happens at the beginning of the project, when not a lot have been written.
> That’s why having AI generate teams of code doesn’t work for me
It also doesn't work for me. Because it's always too much implementation details at the beginning of the project. I'm keeping things loose on purpose while I'm exploring the domain. And when the times comes to finalize, it's mostly copy and paste as I have all the snippets I need. It can serve as good examples though for libraries and frameworks you don't know much about.
So for a software project, I break it into parts recursively. Sometimes for a module, I can build some scaffolding even when I'm not sure about the full implementation. I can go up and down that tree of problems and I always have something to break away from my current thinking track. So there's always a lot of placeholder code, stubs, and various TODO comments around my codebase. And I rely heavily on refactoring (which is why I learned Vim, then Emacs as they helped me with the kind of quick navigation I need for that approach). Also REPL and/or some test frameworks.
[0]: https://www.youtube.com/watch?v=prQH5V5inbA