In order for a software project to be successful, two things matter. What you code (the features you choose to develop) and how you code it (what technology you use, how easy it is to change, etc.)
These two constraints balance against each other, and neither is really more important than the other. If you code crap relative to what you need to code, then what you deliver won’t be good. However, it’s also important to recognize what drives what:
That is, what ever features/design/scope of what you’re building should drive the architecture/style/technology/patterns of how you code it. Picking the right before the left is putting the cart before the horse. Understand what you’re building, what the vectors of change will be, how large the application will be, how complex in which areas it will be, and let that drive your decisions on what framework/technology/patterns to use.
Once you know HOW to use a technology, the next step is to know WHEN to use that technology, and more importantly, when not to. Clients don’t care about code, but they do care about a bad product. Know what’s important here, and make sure that the code is merely the means (a very important means) to an end.