Josh Sherman
I consider myself a PHP developer first and foremost. I don’t tout myself as a Pickles developer (my own framework) or a WordPress, Laravel, CakePHP, Django, Flask or Meteor developer even though I have working experience with all of them. At the end of the day those frameworks still require that you have a core understanding of the language it’s built on.
That all being said, I’ve been asked more and more frequently why I still use / maintain my own framework. Quite frankly, I’m a little sick of the question because the short answer is “because it works and I can work quite fast with it”. Not to mention that it’s been used to build platforms that have scaled to tens of millions of monthly pageviews as well as handling a millions of dolllars of monetary transactions a year.
Sadly, this answer tends to be negated due to the fact that there are larger and
arguably better maintained systems out there. I don’t deny that these systems
exist nor do I feel like I’m missing out too much because I still leverage the
myriad of packages out there via composer, npm or pip when developing
something myself isn’t practical from a time investment or learning curve
perspective.
On top of being asked “why?” so often, I’ve also had my skillset put into question due to the fact that I have developed my own system. For me, having my own framework is simply a way for me to set my own knowledge and best practices into motion while still allowing me to do what I love to do, which is to code. Having my own framework doesn’t make me any less of a developer because at the end of the day, I have a strong working knowledge of the language itself.
One valid point regarding all this came from Ryan Parman who pointed out that it seemed like I write quite a bit of small libraries that already exist. To his point, he got to see my GitHub when I was breaking my framework apart and was thinking of keeping those components around just for posterity’s sake. Keep in mind that my framework actually predates many of the modern frameworks and PHP package management as a whole. Truth is, I sorta have a code hoarding problem. Since that conversation I went through each of those libraries and found existing packages that provide the same (if not more) functionality. Blog post to come on that ;)
In regard to being so reliant on leveraging third-party code, I wonder about the code quality of these seemingly blind inclusions. Just because something has already been written doesn’t mean it’s the best code out there. Let’s be honest here, the package management systems out there are pretty unregulated and full of noise / duplicate packages. You can go with the package that has the most downloads but that guarantees nothing.
WordPress plugins are a prime example of this. More often than naught WordPress installations are compromised not due a flaw in the core but because of a faulty plugin. The plugin makes your day easier and saves you time, but if you don’t take the time to understand / review the code you could be setting yourself up for disaster. This obviously can change with the popularity of the project, the more eyes the most likely issues are to be uncovered and patched.
For the record, even though I’ve had my skills put into question, I’ve never
once been asked to code something in a specific framework on an interview. Most
companies that are doing a good job vetting candidates are interested in your
ability to problem solve and actually code a solution, not do a composer
install on an existing library. So yeah, who fucking cares if I continue to
hack on my pet project?
