Software development is a tricky business. You are constantly trying to balance flexibility/configurability with easy of use and deployment, while at the same time trying to figure out how your audiences' preferred work-flow balances against writing code that can perform at an acceptable speed placed against writing code that you can manage six months from now. And those crazy business people and managers expect you to do it all inside some arbitrary time frame.
It is a system of compromises; success is highly dependent on getting as much information as possible and making the right compromises. Making the right compromises can become impossible if you completely refuse to ever take a risk. Some of the best, most exciting, and enjoyable projects I have ever worked on were started because the team I was on all agreed that the reward was worth the risk. Things like Scrum, Waterfall, Iterative, etc. were all defined to help mitigate the risk; however, process is useless if you are incapable of common sense reasoning, being able to explain your stance, and empathize with logic beyond your own.
Software development is also about pattern recognition. Making the right choices about risks is much easier if you have experience and can identify patterns in behavior sooner rather than later. This relates to everything from judging the character of the people you work with on your team, to identifying the similarities between two apparently unrelated bugs. Pattern analysis is one of the fundamental components to software development. Being able to recognize design patterns when you see them is helpful, but definitely not the purpose of this paragraph.
I cannot say this enough: understanding your audiences' work-flow is one of the most important things you can do. Unless you are writing applications for yourself only, you need to understand how the audience for your application will want to use what you develop. It doesn't matter if you develop the most technically advanced application on the planet that has much more functionality than the audience needs. If the audience cannot understand how to properly use it, or cannot wrap their head around what you wrote, your app will quickly be replaced by something less advanced, does 60% of the requirements, but has an "easy-button".
Microsoft has an entire business model based on work-flow development. I am sure someone in the open source community has a similar project; I have no idea what it is tho. But the fact that Microsoft (one of my least favorite companies) has put effort into making work-flow development easier shows how important work-flow development is becoming.
Combine all of this with a positive attitude and more of your projects will be success; although, it doesn't hurt if you are also Smarter Than A Fifth Grader.