Programming

I found that starting with a "critical path" analysis was very useful. Basically, identify which components or activities need to be at least somewhat functional in order to deal with a different component or activity.

This gives you a list of problems you have to solve in the order they need to be solved. That is, there is no point spending time on writing to disk until you've figured out what you're writing to disk and how your going to collect whatever needs to be written.

Virtually every critical path will have some easy stuff on it that needs to be in place before the hard stuff. That gets you (or at least me!) in the right frame of mind and builds momentum towards the goal. I've often found that doing the work leading up to the hard part made the hard part easier, at least partly because there is now a concrete problem ready to solve instead of a nebulous wondering how to approach it.

Note that if you try this approach, make sure that you avoid the common practice of building "placeholder" stubs for anything other than components further along the critical path than your current position. Even with that, I found little value in stubbing something in before I was actually getting close to the point of needing it in order to continue working.

Note that this process doesn't mean it's not appropriate to go ahead and identify where the dragons are and check to see if you have what it takes to slay them. Back to my example of writing to disk, if you've never written anything to disk before and it looks scary, it might be a good idea to create a completely unrelated toy project to learn and practice that specific skill. After all, if it turns out to be impossible to write to disk, there is no point starting a project that requires it. I find that these toy projects are simple in the sense that there is only one thing to worry about, so you're already doing the easiest thing available.