You are not your Framework 
Tags: webdev, programming, php, beginners
Published: 2018-01-31 08:30:32

---
title: You are not your Framework 
published: true
description: Don't BE your favourite framework. A wake-up call.
tags: webdev, programming, php, #beginners
---

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](https://twitter.com/CiPHPerCoder).

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"](http://www.phptherightway.com/). 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](https://medium.com/the-falconry/skinny-models-skinny-controllers-fat-services-e04cfe2d6ae)_!

## 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._