I struggle with this too, and two things that help me are:
1) Start screen recording software and dictate your thoughts as you go through the research/brainstorming phase. Don't often go back and view the recorded sessions, it's the act of recording and speaking out loud that helps.
2) Comment driven development. Stub out functions just with comments, write deeper comment blocks inside a procedure where you have a rough idea of what needs to happen. I paste in table and API definitions as comments too, to avoid having to flip to a different screen which inevitably leads to distraction. Once the program is completely laid out in comment form, and compile/runs with just "STARTING" and "STOPPING" displaying, then I start implementing what's in the comments outside-in (from highest to lowest level). I run the program frequently while doing this, each successful compile/run is a small dopamine hit. As I'm going through, remove any comments that are duplicated by code - all that should remain are comments explaining "why".
I also the second approach a lot and it's helped my focus immensely. Sketching things out in comments and detailing / changing as you go along first helps curb that initial perfectionism of feeling like you need to write the right code on the first try. YMMV, of course, but worth trying out.
Your advice about comment driven development is similar to how I felt when I first started writing unit tests. I'm not even very good at them yet, but trying to write the tests before the code exists is immensely useful in trying to work out what I want that code to actually look like. Before tests, I would often stub out functions with console logs before writing the body, just to get the high level structure worked out before I got lost in the details.
There's probably a few different methods to do this (some of my friends swear by pseudo code, others have personal white boards) so it might be worth trying a few different approaches to get over your writers block more consistently.
Thanks for this comment -- I'll put the second strategy in effect (the first one perhaps I'll leave for later as I currently work in an open plan office).
I wonder if this "comment driven" strategy has potential for applying NLP+code generation. I'm sure this is a common enough thought but I'm not aware of the research, does anyone here have pointers?
What I mean is: use NLP to extract intent (where feasible), and then offer possible implementations of the intent.
That second approach has been crucial for me when I start large projects. I usually use a mix of comments, pseudocode, and semi-correct actual code, then go back and fill everything in one-by-one.
1) Start screen recording software and dictate your thoughts as you go through the research/brainstorming phase. Don't often go back and view the recorded sessions, it's the act of recording and speaking out loud that helps.
2) Comment driven development. Stub out functions just with comments, write deeper comment blocks inside a procedure where you have a rough idea of what needs to happen. I paste in table and API definitions as comments too, to avoid having to flip to a different screen which inevitably leads to distraction. Once the program is completely laid out in comment form, and compile/runs with just "STARTING" and "STOPPING" displaying, then I start implementing what's in the comments outside-in (from highest to lowest level). I run the program frequently while doing this, each successful compile/run is a small dopamine hit. As I'm going through, remove any comments that are duplicated by code - all that should remain are comments explaining "why".