I'll keep it short, to avoid spending too much time on HN when other stuff should be prioritized, so apologies for repeating things that others have already said. ;-)

What I do is three things from the OP, and one extra thing:

- break down things into chunks (divide and conquer is what computer scientists are trained to apply)

- reward yourself (after each mini-step, I grab some chocolate, after certain time units, I will make a short break, and after the complete session if I'm satisfied with what I have achieved, I might order myself a book from my online wish list ;-).

- The third and most important part is start by picking a small and easy task. In many cases, the problem is easier to solve and less painful to complete than it appeared before starting to tackle it; once you're on it, things get easier and you may soon enter the flow and then things start to fly & rapid progress may ensue. I circle around the hard parts fixing a bunch of easy things that I know are easily and immediately solvable. Going around Mount Everest and depleting bits from all sides, suddenly it's not that big and scary anymore, and I have already understand bits from different parts, so my mental model of the problem as a whole approaches what's left of the real Mount Everest, not a huge mountain behind a wall of fog.

Curiously, I'm successful with that technique, and I have a friend whom I also consider successful who does it the other way round: he starts with the carved-out core problem, and once he knows how to solve that, the rest is just code writing approaching boilerplate-level. And before that, he does not bother with addressing all the other stuff, the "mere periphery".

I call my method outside-in and his method inside-out. In theory, I appreciate his method, but in practice, my method makes me more productive, because even on a very bad day (say, a zero flow, mega-unproductive day, which happens, but thankfully not that often), I can write a logger or a test harness, and once I've done any of these easy bits, the dopapine reward will motivate me to solve harder parts & because I've started to write code or whatever it is I need to do that I was postponing/dragging out, I'll be more likely in the zone and will be able to do the harder bits of it.

BTW, don't confuse the *order* of doing things with the kind of *abstraction* in software architecture (where I would consider myself a top-down thinking person that consciously combines top-down and bottum up approaches to ensure the pieces fits together and each piece can be build). The two are related, but not the same thing.