I'm familiar with this. There's no magic solution, sadly, but I'll share one thing that has helped me and may apply at least to some of your situations.
I realised a while ago that my main issue was with nebulous tasks -- that is, the more concrete, defined, and _meetable_ a task was, the less trouble I had with it. So I started to break down large tasks, which never got started much less finished, into smaller ones, in the same way you might break a scrum-poker 20-pointer into a bunch of 3s.
You want to go from this:
- I should really write [some great app idea]
To this:
- I'll make a list of technologies that I want to use
- I'll read the docs, like a book, for the ones that are new
- I'll write a single api endpoint
- I'll flesh out the api for the rest of a feature
- I'll MVP a UI for that one feature, without any concern for design
- etc.
In my case, a combination of the size of and amount of ambiguity in a task is inversely proportional to the ability I have to both get it underway and get it finished.
I realised a while ago that my main issue was with nebulous tasks -- that is, the more concrete, defined, and _meetable_ a task was, the less trouble I had with it. So I started to break down large tasks, which never got started much less finished, into smaller ones, in the same way you might break a scrum-poker 20-pointer into a bunch of 3s.
You want to go from this:
- I should really write [some great app idea]
To this:
- I'll make a list of technologies that I want to use
- I'll read the docs, like a book, for the ones that are new
- I'll write a single api endpoint
- I'll flesh out the api for the rest of a feature
- I'll MVP a UI for that one feature, without any concern for design
- etc.
In my case, a combination of the size of and amount of ambiguity in a task is inversely proportional to the ability I have to both get it underway and get it finished.