About a year ago, I was introduced to Zend Framework as the framework I was going to be working with almost every day. And for nearly a year now, every day I have worked closely with Zend Framework, learning it’s intricacies and dealing with its warts. I sat down in March of last year and wrote a case study about learning Zend Framework. A year after adopting it seemed like a good time to reevaluate the framework and reflect.
Learning Zend Framework was a daunting, challenging experience that tested myself and those I worked with. I learned a few lessons that I think are important, and I think are worth sharing.
Learning new tools is not easy. The tool you pick doesn’t change this fact.
Learning a framework is tough. It’s hard to get involved, it’s sometimes difficult to read the documentation, and the paradigms which are so familiar and obvious to the developers and users of a framework are foreign to you. But that’s just part of learning. It’s the way it is.
Think back to when you first started learning PHP and the struggles you had with it. They seem so far, so foreign today, and yet for many of us it was a few years ago. Learning a framework is akin to learning a new language; while the syntax of the old language doesn’t change, the resources, tools, libraries and components available do. The paradigms shift and require us to rethink some decisions. And this is normal. It’s okay.
The framework you pick doesn’t make the transition any easier. They’re all difficult in their own ways. While some are better designed than others, none of them is easy to master in five minutes. Placing this expectation on ourselves or our tools is setting ourselves up for a failure.
Dive in wholeheartedly.
If we recognize that learning new tools is hard work, the only thing we can really do is dive in with our whole hearts. This is the key to learning: immersion. Immerse yourself in the framework; use it every single day for a while and refuse to step back into old habits or old tools. Determine that this is the path you have picked, and you’re going to stick with it.
One thing I see too often is people pick a framework, but then fight the framework tooth and nail. Rather than learning the ways in which it’s implemented, and the methodologies behind those decisions, they reimplement methods or components because they need them now, and don’t want to take the time to do the research. This is a fast way to failure. Diving in wholeheartedly means accepting that the framework’s methodology is one that you’re going to make use of, for better or for worse.
Don’t doubt your decision just because it’s not working for you today.
There are going to be days when working with the framework seems to be the worst decision you could make. The good news is that it gets easier! Day after day, working with the framework, it gets easier and easier to implement.
It’s easy to say “this isn’t working” and become discouraged or even abandon the idea of using a particular framework. I know I had days like that, especially early on. But the reality is that the decision you made is not less valid today than it was last week. Sure, perhaps there are some frameworks that we should discard, but chances are good that you can accomplish what you’re working on with the framework you’ve picked.
Frameworks are fantastic tools that typically make the development process easier, but learning them does come with a cost and developers must understand the importance of sticking with it, sometimes for better or worse. Like any tool, frameworks can be beneficial or detrimental, but when used properly and given the time to learn them, I’ve found them to be extremely beneficial.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."