[cven714]

I have the exact same problem. When I know what needs to get done, even if it's tedious, it's not so bad to put my nose to the grindstone and work through it. But when I'm not sure how to approach a task, suddenly every distraction in the world is more appealing.

You often see the suggestion to break up big tasks into smaller, baby step chunks to avoid this analysis paralysis. Doesn't help when I'm not even sure what to do yet.

[ianmcgowan]

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".

[bschne]

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.

[zeta0134]

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.

[flancian]

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.

[li4ick]

Microsoft is investing quite heavily in generating code from requirements. So far, iirc, they're able to generate simple programs no bigger than 10 lines of code. A good start, though: https://www.microsoft.com/en-us/research/blog/learning-sourc...

[meowface]

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.

[Sir_Cmpwn]

From my experience, try having enough projects in your belt that at least one of them has something actionable to do, and work on that while you ruminate on the other problem for a few days/weeks/months. Don't worry about getting anything done soon, prefer getting them done correctly and pick something else up when you get stuck. Also, don't forget that "staring into space for an hour while you think about a problem" is also a valid form of working.

[ehead]

This is my solution, but it feels like there should be a better way.

I have replaced 'staring into space thinking' with taking a walk outside my office.

[zikzak]

Unless you are rich enough to have chosen it, or maybe a prisoner, you always have more than one thing to do. Laundry, groceries, complex engineering, it all needs to be done.

I think our minds evolved to track all these things and, probably in a time sensitive way more than projected future value, to prioritize them. For this reason, I think having multiple projects is the natural state as the mind is optimized for this. So maybe this is the "best way" and explains a lot of the strange ways in which putting a problem aside can help solve it.

[fwip]

It's hard to do laundry or grocery shopping while you're at work.

[collyw]

I like to work like this as well. Which is why a lot of technical tests seem quite nonsense. For complex problems I have stuff running in the background of my head for a day or two, weighing up the advantages and disadvantages of the various options. The best solution usually becomes apparent at some random time, like when I am cooking dinner, not concentrating on it for 5 minutes after first seeing the problem. And as you say there is usually plenty of other work that needs done in the meantime.

[cgriswald]

Figuring out how to approach a task is a problem that can be broken down all on its own. Make a list of possibilities (even if they are “dumb”). Work through them. What happens for me is that either one of them is right or (more frequently) I suddenly “get it” and it’s off to the races.

[ivanhoe]

We're all different... I enjoy figuring out the things, but when it's time to start implementing it I've already lost my grit partially and that's when I start procrastinating the most. Once I move past that milestone and start doing the actual work it gets much easier again.