You are not your Framework
Nick Cinger Jan 31, 2018 Updated on Feb 04, 2018
There is a worrying trend developing among web developers that should be raising red flags in the community. We've gotten so good at promoting Best Practicestm, Best Frameworkstm and Don't Reinvent The Wheeltm, that we forgot to let new developers make their own mistakes, and learn the ins and outs of webdev in the process.
Code boot-camps, intern positions in companies and online forums alike have drifted towards pushing the greenhorns to "just use the framework". Sure there are tedious things they shouldn't be re-writing on every project, like authentication, input sanitizing and cache handling, but they are missing out by not learning how it's done. Except for encryption: Don't roll your own crypto. Unless you're this guy.
And I get it, you're new, time is short, you want to skip all the checkpoints and go straight for the finish line. So now you're looking at job postings, online discussions and blog posts to find out which is the best framework to use. Depending on the current year it might come down to a choice between Laravel and Symfony, or maybe CakePHP, Yii and Codeigniter. So now you have your framework and you steam-roll through the "build a blog" tutorial within a single weekend. You venture online proclaiming that you know all there is to know about this so-called MVC paradigm.
"I just put my HTML/CSS _here, my database stuff there and my session stuff all over the god damn place, and _look Ma', I'm doing MVC!".
Great, this is already a lot better than that mess of includes and requires you had with
functions.php on every damn web request. Now all you need to do is tell the framework what you want, and poof you've got some instant
bloat feature on your hands that does stuff you don't see and don't even try to understand.
A week later, you have the Frameworktm sticker, it's on your CV listed under "proficient in:" and you're calling yourself A Web Bagel Meister.
And this is perfectly fine. If you're 1-2 years into web development. There's nothing wrong with putting on some training wheels. But for goodness sake learn to ride a bicycle after a while - don't just title your portfolio "Tricycle Expert".
Red Flags for the Hiring Process
It's your right to look for the kind of work you'd like to work on. It's also a reality that a lot of what's out there is going to be work on existing, potentially legacy systems. And there's a good chance it won't be written in Frameworktm.
If you're shown a piece of the system and asked how you would improve this code-base, and your immediate response is "I would rewrite it all into Frameworktm" you're going to get a polite smile, a nod and your printed CV in the bin.
Your favourite framework is not the solution to everything. I know you have a shiny new hammer, but we're not going to let you chop wood with it. Re-writing a multi-year code-base in your favourite framework is NEVER-EVER a valid business decision.
There's a case to be made for migrating an old system by writing new features in a separate fresh codebase, and gradually moving bits and pieces out of the legacy system. But I've recently had too many interviewees and new hires think that re-writing a decade-old project into the current hotness is a good idea, to consider it a slip of the tongue.
I've asked people to do simple stuff, like loop over results, write to a file and use an existing Model and
findById() method. The interviewee with 5+ years of PHP experience reached directly for classes and helper functions from their favourite Framework, even though the task was explicit in making the new Class decoupled. As if there is something inherently dirty in using
"But how can I get out of this and move on with my skillset? Tell me it's not too late senpai" - you sob as you cling to my kimono. It's not too late, and here a few guidelines:
Don't be a Frameworktm Developer
Be a Developer, with MVC framework experience, and hopefully some vanilla PHP to back it up. Learn about Design Patterns. Read "PHP the Right way". Do not participate in Framework Wars. I repeat, do not participate in Framework Wars.
If you get all defensive every time someone critics a tool you use, it might be time to step back and rethink your position.
Write decoupled code
This will force you to actually learn OOP PHP. No, you're not giving up all the niceties of the framework by doing this - you're writing cleaner, more maintainable code that's easier to test. Do it, you'll thank me later. And if in 5 years you decide to rewrite it in your Favourite Framework+1tm anyway, this will make it a lot easier.
One of my biggest "A-ha!" moments was when I realized that I'm allowed to actually create my own folders and class types within the framework directory structure. You mean I can write my own
CleanerProxyFactoryGenerators, and I don't have to cram it all into Controllers or Models!?? Bye bye Fat Models, hello Services!
Get under the hood as often as possible
If you don't learn how the magic works under the hood, you're at risk of being bitten by weird bugs, or being stuck in debug hell for days at a time.
Sometimes you don't really need that framework method, many of them are just bloated
foreach loops or array manipulators. Yes, it may cover more edge-cases, but it's open source: take a look and make an informed decision on whether to use it.
If you're blindly doing things the Framework Waytm, you won't understand the performance cost associated with it. There is nothing inherently wrong in using vanilla PHP/JS/Ruby to solve the problem, and there's a good chance that it'll solve the problem an order of magnitude faster.
Continue learning and trying new things
It's going to be hard to become an evangelist for a single framework once you realize that it's not the end-all to web development. More than likely, it does a lot of stuff right, and a few things wrong. This becomes more apparent once you know frameworks with different subsets of correctness and wrongness.
All in all, as long as you're aware that there's a problem, you can be helped. It's a natural part of learning, but as such it's a stepping stone that you need to move past.
Unless you're using CakePHP, in which case you're golden, and don't need to change.