This may come across as facetious and/or condescending, despite my intentions to be to give actual advice here... Learning TDD is what helped me get past this. It's surely not the only way to do it but it really made it click when I did.
In learning the craftsman style of TDD (i.e., the fluffy altruistic style) helped me to grok breaking down tasks, not because I wasn't able to have a detailed view of the big picture in my head, but because I simply didn't need to. It's also ok to change what you've already done. The guidelines for code modularity and separation are there to make this process of change and evolution easier, not just to make the system arch and code pretty, but because it should be expected to change and evolve your code as you develop the system - in both the short and long term.
It doesn't come across as facetious/condescending. Thank you for your advice.
I'm actually using a TDD-ish approach in my work, but I never felt comfortable letting it actually drive design decisions. I don't believe it works that way - I can explore the design space up front and pick good solutions faster than it would take me to organically arrive at them through applying orthodox TDD.
I'd like to do more TDD-ish approach, because the design process feels way too slow to me. The problem is, refactoring involved in test-driven design discovery is even slower. I constantly feel bottlenecked by the speed of tooling we use - and not on the surface level (I have my Emacs configured well, thank you), but at a fundamental one. Programming languages are not expressive enough. The whole approach of writing code as plaintext document is not ergonomic enough.
When I'm sitting in front of an empty text file, staring at the sea of infinite possibilities, all I feel is dread - the fear of how much effort I'm going to spend fighting tools to conceptualize my design, how much time I'm going to waste dealing with infrastructure, build systems, dependency management, constructing intermediary layers, writing and rewriting tests...
I start at step 1 in the task I'm trying to accomplish. First write the main function then put in the first thing your program needs to do.
I guess I usually have a plan before I even sit at the editor of what I'm going to accomplish with the project. You don't have to know all the classes and data structures you'll need at the start, you will discover it along the way when you find you have data you need to group together or code you need to call in multiple places.
I think of writing code like writing a list of instructions to tell the computer how to do something. The natural place to start is step 1. Then of course you can start roughing out the major steps in order and filling in the details once you have something you can run and start testing parts with (either manually or automatically).
This resonates well with me. I too have my Emacs well configured and I dread the blank canvas. I think it also might have to do with me being an avid procrastinator.
In learning the craftsman style of TDD (i.e., the fluffy altruistic style) helped me to grok breaking down tasks, not because I wasn't able to have a detailed view of the big picture in my head, but because I simply didn't need to. It's also ok to change what you've already done. The guidelines for code modularity and separation are there to make this process of change and evolution easier, not just to make the system arch and code pretty, but because it should be expected to change and evolve your code as you develop the system - in both the short and long term.