I enjoy the way a problem's appearance changes as you get deeper into it. I'm pretty deliberate and systematic in tackling problems, but I usually find that my plan changes dramatically as my understanding of a problem changes.
I start working on a problem, I poke at it a little, and make my first effort. I notice a new wrinkle, and adjust my plan to accommodate that. In the end, I find that I have a pretty good grasp of the problem, which feels great.
I was listening to a JavaScript Jabber podcast about Ember.js and Ember contributor Trek Glowacki made an interesting point in Ember's defense. He pointed out that the more comprehensive and opinionated a framework is, the easier it will be to get people up to speed on contributing to your application.
The code you have hand-written today totally makes sense to your team right now. But 6 months or 12 months from now, when it’s a different set of people...they need to get in to your app and learn everything from square one. Whereas if you’d been writing this in Ember and they are people who knew Ember already, the surface area that they need to understand for what is custom about your applications is much, much smaller. And that makes skill sets just way portable. [When onboarding developers onto an Ember project], I wouldn’t have to explain particular ways that we were doing memory management or particular styles of programming or particular organization techniques that we had because I can just assume that they know that because they are an Ember developer...That is a huge benefit.
I noticed this effect recently, when I was looking into contributing to an open-source project. I spotted some issues with the UI, and saw that I could pretty easily fix them because they were using Bootstrap (front-end framework). I worked with Bootstrap components a good deal at my last gig, so it was all quite familiar. By using a common framework, they have made contributing easier, which is probably pretty important to them.