Recently I’ve been immersed into a Zend Framework project in a way that I’ve never been immersed before. This immersion experience has brought out a few thoughts and lessons that I’ve learned through the process about how to get into a framework, how to start a new project using a framework you’ve never used before, and the best way to learn without losing your sanity. Here are my findings.
Don’t fight the framework.
Various frameworks out there have varying degrees of integration with one another. While an argument can be made as to whether or not tightly integrated frameworks are better or worse than loosely integrated frameworks, when starting a new framework it’s best to accept it lock, stock and barrel (in other words, accept it completely).
This isn’t always easy for developers. They have a particular problem they want to solve and often times solving it with a framework they haven’t used requires a lot of setup, a lot of learning, and a lot of banging their heads against a wall. I know for me this is true whenever I start working on a new framework or product. But this is an important component of using the framework. When we try and go around the framework, when we fight the framework, we ultimately end up doing a lot of the things that the framework is aimed at keeping us from having to do.
Embrace the framework. Once you’ve learned it and mastered it, you can go around it, fight it, and ignore it if you want. But until that point, ignoring it will only lead to more headache and frustration – especially when you discover the framework was doing something you were trying to do all along.
A little knowledge can be very dangerous.
When I was starting to get in depth with Zend Framework I felt pretty good. I was getting a good grasp of how it worked, and I was mastering the idea of MVC, Zend’s way. I felt like I had learned the basics of Zend Framework, and I figured I had at least graduated to intermediate.
Until I realized I hadn’t done anything interactive with GET or POST. Whoops!
Having just a little bit of knowledge in a framework can be very dangerous. Thus, it’s important to be careful when developing, to make sure that the level of development matches the level of understanding. Don’t start with your most advanced, most difficult logic when starting with a new framework. Do something easy – like display the publicly facing portions – rather than something hard. You’ll find that you learn at just about the same pace without having to rewrite your application when you learn about better practices.
Learn when and where to ask for help.
Chances are good that any framework has a strong community around it. If it doesn’t you should consider one that does. Chances are also good that the documentation isn’t the best. That’s ok. Just learn when and where to ask for help. Learn who is willing to talk you through things, and have good questions ready for when you’re talking with those individuals.
For me, Matthew Weier O’Phinney answered a lot of questions. So did Matthew Turland. Both of them were great helps, and there are lots of other great members of the Zend Framework (or Symfony or Cake or…) communities out there, ready to give you a hand.
A word of caution: when asking for help, be sure to thank and respect those who help you. Most of the time they’re doing it for free, even if their day job is to consult on these products (or build them, in MWOP’s case). They don’t have to help you, and if you act entitled, they simply won’t.
Learning a framework is much like learning a new language. Have patience for it. The reward is great – framework knowledge can be reused over and over again. Being patient and taking the time to learn means that the knowledge will be valuable, rather than being bits and pieces of a hurried experience (which is far less valuable). A holistic understanding of the framework will serve you well, as a developer.
If you decide to endeavor on your own journey with a framework, good luck! It’s a challenge but it’s well worth it. Learning a new skill has it’s own inherent rewards, and you’ll thank yourself later.