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 Practices^tm, Best Frameworks^tm and Don't Reinvent The Wheel^tm, 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 footer.php and 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 Framework^tm 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 Framework^tm.
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 Framework^tm" 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 file_put_contents().
"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 Framework^tm 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+1^tm 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 Way^tm, 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.
Top comments (37)
I remember writing my own terrible CMS that my website ran on for years. Would I use it now? No. But the things I learned from building it were definitely worth the time investment - I just loved working on it, learning how classes worked, setting up a database schema for it, trying to secure form submissions and trying to hack my own work. It was fun!
And that's how developers learn!
I did the same, I used to have "Custom CMS building" listed in my freelance profile. Definitely not something to write home about, but it did the job and I learned to appreciate the work that frameworks take care for me under the hood.
Couldn't agree more. I cringe every time I hear "Don't reinvent the wheel", how am I supposed to learn?
Trying to make and use a square wheel can be very educational, and is in no way a waste of time for a learning dev.
Eeeeexactly. Doing it for an on-the-job thing where time is an issue and there are a bunch of other factors? Totally different story. But for side projects and your own edification? Oh hell yes.
And sometimes, it turns out to be a pretty darn useful non-square wheel in the end. See also, Please Reinvent the Wheel...
Great minds think alike, or some such :)
Thanks for sharing!
This is so beautifully put, it makes me grin from ear to ear. THANK YOU.
Especially...
Goodness, you just described a good 2/3 of the industry!
To put this in even more relative terms, don't bind yourself to abstractions. I make a point to always know what's going on under the hood of any abstraction I use - language, library, framework, toolkit, whatever - and to be flexible enough to move from one abstraction to another.
And yes, that means I eventually work my way down to a basic understanding of Assembly. If you're not willing to touch there at some stage in your career, you're in the wrong field. ;) [But, by all means, take 20 years to get there if it takes you that long.]
Thank you very much for the kind words!
Agreed on going lower into the tech stack. It's not mandatory, but it'll help you understand how it all comes together. It comes especially handy when doing serious optimizations.
Inevitably the frameworks will fail you, so yes, learn how to dig in deeper and change things.
I can assure new programmers that the idea of a "best practice" is tenuous. They change all the time, and there are several competing ones. This isn't an invitation to invent everything from scratch, but feel free to tweak the best practice to accomodate your project.
One thing I've learned in eight years: there's no such thing as Best Practice.
We have Good Practice. Learn it well, and use it until you have a reason to depart.
But there is no Best Practice, because it is saying there is One True Solution To Solve All Problems, and literally the entire history of computers proves that premise ridiculous.
I wrote my own version of MVC and also tried creating a custom CMS, am glad I did that it made me invest in a proper framework, and for each I always read the internals to understand the Philosophy before picking it up. I would never take a Framework popular for magical methods and all, because that would increase debugging time for me. It's important to know the underlying concept and practice while using a Framework.
So true ;) This remind's me a lot of @vaidehijoshi and her basecs ;) Make sure you understand what's behind the curtain.
That's awesome!
I don't know at what level your own framework is, but there's no harm in learning one of the bigger more popular frameworks. Chances are they handle a lot of what you may need. And with you knowing the ins and outs of a framework, with it's routing, request handling etc, you're probably ahead of the curve on a lot of the technical bits.
There's a place and time for the popular frameworks, and a lot of advantages to using a battle-tested one as opposed to your own. Don't write it off out of hand, more so because you probably won't have trouble learning how to use one.
That's awesome :)
Composing a framework like that is a good way to go.
young people do this crap because they feel like the places other people crowd around (frameworks) are more valid than themselves because people who are inexperienced or young (like me) dont like to self-actualize.
self-actualization is difficult for everyone, even those who are self-aware, and the especially anxious ones dont want to get their feet wet with trying it the way that involves
file_put_contents();and similar length functions or with actually using the language's constructs likeforloops. its like using shiny new es7 iterables over a simpleforloop.im constantly in anxiety with my code that whatever i write is "impure" or like youve alluded to doesnt follow "B E S T P R A C T I C E (tm)". i go with express rather than native node.js http functions not because its easier, like with automatically sending back headers and formatting json, but because it feels more "right" to do so.
ironically what keeps us young bois from healthy challenges like critically thinking is unhealthy challenges like fear of failure or fear of missing out.
I can relate to this very much.
I've used the framework tools constantly, just for the fact that they must be somehow better than using the language constructs directly.
After a while I started hitting odd bugs within those methods, and I started digging into them, only to realize that they're usually over-bloated, and that they merely wrap around the language constructs.
Not to mention that they caused performance issues with huge data sets, where a every bit of memory saved was important.
After this happened a few times, I made it a habit of actually reading the code for the internal framework tools. Granted, this was easier with the older frameworks as the more modern ones are abstracted into oblivion. It's still possible with the new ones as well, once you go beyond the initial fear of seeing things like Traits, extensions and interfaces.
i do this too with documentation. i often try to break things down or try to reimplement things on my own time so i can understand whats going on in an intuitive way. you can be a lazy js developer and copy and paste
app.get("/bla", (req, res) { do stuff(); });or you can break it down and understand it.i dont even count as anywhere close to a junior developer, but something ive noticed about professionals is that the more "professional" you are, the more you can make yourself seem like you know what youre doing
It's all "fake it 'till you make it" :) Experience you'll come by with time, but having the right attitude and approach will get you far, so try and hold onto that!
One of my "life hacks" for learning new things was to NEVER copy/paste. I'd always force myself to type it out, even if it meant ALT-tabbing 10 times. Helps make the new code "stick" and get into muscle memory.
the future is now old man
Question: does that mean I need to learn C before I can write any PHP? If you follow this line of thinking all the way down, a framework is just another language on top of PHP in userland.
I think the intention is good in your post. Learning the tools takes you from beginner to journeyman, and mastering them makes you a craftsman. That takes years of work.
Frameworks are excellent at hoisting up beginners while they learn how to code, and as they get deeper they will naturally gravitate towards learning more of the "magic".
Uhm, well no, that's not what I'm aiming for, but a parallel can be made. For example, if you want to be better at optimizations and handling memory, then yes, please learn C. I know it helps me in my work. For that same reason, you should learn how PHP Sessions, Requests and Headers work, to be an effective web developer, even while using a framework.
As to whether you need to, that's totally up to you. But you would definitely be better off for it.
Usually, I would agree with you, but I've been encountering a different reality in which experienced developers never grew out of their favorite framework, and never learned what the cost of the "magic" is. Hence this post!
Great article!
I got my first job 10 years ago because of my horrible CMS I made from scratch, that's the best way to learn.
If programming was to be compared to art then frameworks would be "paint by numbers"
Another point that I realised at some point is that, as others said, frameworks will fail you.
Even if you don't decide to move onto to a new shiny framework, the one you currently use, and have used for years, may just start going on a direction you rather not follow.
Alternatively the web, users' or your workplace's may change, making it harder for you to deliver solutions inline with those new requirements whilst abiding by the rules your framework imposes.
I think that in summary, accepting that frameworks (and even languages to a degree) are just tools for the job will make things a lot easier in the long run.