PHP

There is a topic that’s on my mind for quite some time now, and recently more of the pieces fell into place. There are multiple angles to it, so let me just get to the point.

I am running a product that has a backend part written in PHP. Yeah, I know. This means that I need to have access to the so-called talent pool of PHP programmers. This would allow me to grow the team, or fill in vacancies. The PHP talent pool is shrinking, there is nothing I can do about it, and that’s not good for business.

How to think about the talent pool

There is a certain number of people willing to work in a PHP developer role. This number fluctuates, and two things have a direct impact on its size:

• The number of new software engineers entering the talent pool: both junior devs, or people with experience changing their technology
• And the number of people leaving the pool: by retirement, changing technologies, moving to management track, and so on

And there is one particular thing that influences the above:

• Number of opportunities on the job market for PHP devs vs other languages, potentially available to the same people

People entering the pool

One of PHP’s main benefits is its low barrier of entry. You download a LAMP stack, save a file in your web folder and access it via the browser. It just works. Change something, refresh the page, it just works. Make a mistake? Ignore best practices? PHP will do its best to figure out the way. Upload the results of your work to an FTP server: you just deployed to production.

This was true 20 years ago. And mostly even 10 years ago. But then things happened.

The PHP community wanted a fresh start

Experienced developers gathered around PHP wanted to move the language in a certain direction. Package manager, build & deployment tools, strict typing, DIC-based frameworks, more static analysis. Those are both great features of a mature language, as well as ones that increase the barrier of entry for inexperienced devs.

Other possibilities

In the meantime, new contenders arrived. You had django and rails. Both great picks for general, web-focused projects. Arguably rails even better at what PHP was trying: a simple, rapid application development framework, that allowed you to just makeBlog() and be done with it. PHP’s Laravel came to the party a few years later, and while it’s in my opinion one of the main forces that keep PHP alive for new devs, the damage is done.

And of course, this JavaScript thing happened. It blew up. The popularity of JavaScript is undeniable, and along with that, the node backend development ecosystem thrived. How a new programmer can learn JavaScript? Just write some code, wrap it in a simple HTML boilerplate, and doubleclick to open it in their browser of choice. It just works. They don’t even need to download that LAMP thingy PHP devs needed to. And the skills they learn allow devs to write both backend and frontend? And the results of the work are immediately visible? How can you compete with that?!

I’m not able to quantify the impact of the above things, but I’m sure there are only a fraction of new PHP devs in comparison to a decade ago. There still are some, mainly due to Laravel and Wordpress in my opinion, but there are fewer and fewer by the year.

PHP developers are changing careers

To Java

Let’s say it like it is: PHP wants to be Java. It’s moving in a direction of a general-purpose OOP language, copying Java features along the way. And it’s a couple of years behind. So why would you keep lagging, using a language with a bad reputation (PHP is still being looked down upon for its PHP 4/5 days)? Today the gap between PHP and Java is not that great, and making the switch is fairly simple. And it will be even more so over time.

And besides the features, Java has one great characteristic: there are more greenfield projects started in Java. Not so much in PHP. You can find a lot of Laravel apps, but I don’t want to comment about the quality of those. There is a whole market for enterprise’y frameworks like Magento or Drupal. And there are a bunch of large companies with 10 years of PHP legacy code.

This is not something PHP devs signed in for. They wanted those greenfield projects, to follow best practices, and they wanted options for change if they ever decided that its the best time to do so. Instead, they slowly becoming more like COBOL.

To JavaScript

The thing about PHP is, it almost always went in tandem with JavaScript. There were very few PHP devs that weren’t at least familiar with JS. This made it easy for them to switch to this new, booming market. TypeScript came along, and all of the OOP skills could now be transferred to the fronted (or a node backend).

There is a lot of demand for JS in recent years, and it’s only the last five or so when the frameworks got more mature, and as a result — the work more effective. This all led to a ton of motivation for a switch. And by looking at CVs of people applying for my frontend roles — many of them started with PHP (or other backend languages for that matter). I haven’t seen devs switching in the opposite direction.

To management

The third large exodus is out of programming entirely. At least as an individual contributor. People that learned their craft in the 2000-s, when PHP was popular, are now prime candidates to start their own companies, or at least manage teams. Sadly, often this is the only viable career path, and many feel forced to take it.

The effect on the talent pool

For the pool to grow or at least stay at a certain level, there have to be as many people joining as there are leaving. To the best of my knowledge, year after year fewer people are choosing PHP, and more and more are leaving for other opportunities. The pool is shrinking, and there is not nearly enough to choose from.

But PHP is a great, modern language

It is. And it’s a great tool for the job most of the time. PHP 8 did a tremendous job of improving the shortcomings of PHP 7. New features, syntax, and possibilities are arriving in PHP as we speak. This does not matter.

There was another thriving ecosystem two decades ago. Flash. The one from Macromedia, remember? It was a great platform, powered by ActionScript 3 — object-oriented, ECMAScript-based scripting language (yeah, there was a cool ECMA flavor before TS). The format itself was robust and resilient to corruption. A great feat in the, let’s call it, early days of the internet. And it had enterprise tooling too, backed by Adobe.

None of this mattered when Apple steamrolled over it with iPhone. In the five years starting from 2007, Flash was slowly dying, just to be left on life support during 2010-s, just to be put out of its misery on the 1st of January 2021. Over that period, many great developers, game designers, and animators were forced to switch to a new platform.

We can still train people

Yes, if you work in a company that invested heavily in PHP over the years, and has tons of legacy PHP code, you’re left with two basic options:

• Pay the shit out of who’s left on the job market
• Or train juniors in hopes that this investment will payout in the long run

Both of those approaches require a large organization and a lot of resources. My product cannot afford this. And even if it did, I’m not sure the strain and the risk are justified. For what? 100k lines of code written in a language that may or may not be around a decade from now?

What this means strategically

For companies with products written in PHP… Let me put it this way. My product is still small but expected to grow at a certain pace. This means, that somewhere along the line, we will probably conclude, that the backend team needs to double during the next two quarters. Do I want to be the person responsible for hiring 15 PHP programmers between the spring and fall of 2025? I’d rather eat a chair.

For me, the way forward is clear (spoiler alert: it is not in the general direction of PHP). There will be great obstacles to build a team of — for example — Java developers. Both internal and external. Probably this would require higher salaries. Building the stack from the ground up. Technology would be more complicated, and the team split in half. But those are the things — while often hard and require a lot of effort to manage — that are under my control, and I can tackle each problem, one at a time. The number of PHP devs available to me on the job market — I have no say in this.

Switching away

To quote a CTO of a large, mainly PHP-based product:

But my bigger problem is how to deal with the legacy and I don’t see that going away anytime soon.

Yeah, it’s not. Even in my small team, this would become a problem. But what I can do is slow the pace of making more of it. I can start shifting the direction now, slowly, and after a couple of years end up with — maybe — only 30% of the codebase in PHP. This is manageable. Heck, maybe in time this could be handled by those poor Java devs with a little training?

My team has started to think about introducing a new programming language to our stack. The way we want to do it is by starting to make microservices (like, that’s what they are supposed to do, right?), and allowing ourselves to increase the volume of Java, or Kotlin, or TypeScript code in our app. We don’t know the details yet, and the road ahead is dark, scary, and there be dragons. But it is the one we need to take.

It’s time to say goodbye, PHP. It was 20+ years of great adventures, but it’s time to part ways.