A very good mentor of mine once put it succinctly: when thinking about a problem, he said, "don't start with the barriers." Don't frame the thought process as "Here are all the reasons why not; now I need to figure out why." Instead, start from a place of "Absent all barriers or obstacles, here's what I would like to accomplish." There will be plenty of time to address obstacles, but it's best to be energized by them when you get there. If not, you'll see every obstacle as a crushing defeat.
If this sounds new-agey, well, perhaps it is. It's a mindset thing. But mindsets can be extremely critical. There's a huge difference between someone who sets out to succeed and prepares for failure, and someone who sets out to avoid failure and hopes for success. The former will exhaust every option to circumvent the obstacles; the latter will almost look at the obstacles as vindication of a deep-seated suspicion that he's wrong.
First I write some sample code in exactly the syntax I'd like to use, in an ideal way ignoring whether it's possible or not to produce. Then I create a macro to transform that syntax into code, iterating the sample code if I encounter barriers (usually unparseable syntax). It has really helped me (a poor to mediocre scheme programmer) create good macros very quickly, improving the expressive power of my code dramatically.
I would go so far as to say that they are the only thing that matters.
You can look at a problem from one mindset and see that it's going to take you 5 days or 5 weeks. Change your mindset and you might see that it's going to take you 5 minutes.
Another reason to focus on goals rather than obstacles is that it's the goal that matters, and there will be more than one way to get there. Obstacles on a given path may be unsolvable no matter your focus or perserverance, and the only way to solve them is to choose a path where those obstacles are absent. The other paths are difficult to find if you focus on the thing that's stopping you on your current path.
In a sense that's exactly what top-down design is. You work on the big ideas and then come back to the barriers. It helps not just with the mindset but also helps you figure out which barriers matter.
If this sounds new-agey, well, perhaps it is. It's a mindset thing. But mindsets can be extremely critical. There's a huge difference between someone who sets out to succeed and prepares for failure, and someone who sets out to avoid failure and hopes for success. The former will exhaust every option to circumvent the obstacles; the latter will almost look at the obstacles as vindication of a deep-seated suspicion that he's wrong.