Up to this day, PHP still has bad fame. When you are starting working professionally, that might give you a bit of impostor syndrome, because you think that you are not good enough to use a “good programming language” as other people you know. You think that you will become a good programmer once you are able to learn and work with a “professional programming language” such as Python, Java or Go, and stop playing around with toys for children like PHP.

However, as days, weeks, months and years pass by, step by step you are becoming more experienced —that is, if you have the right attitude, the appropriate gaze. One month, you start using a framework that ease your work. Another day you get a grasp on how good and helpful Composer is. Then you start worrying about testing, architecture, design patterns, code readability, SOLID practices…

I think it is sometime in that stage that you start to realize that good or bad code does not have much to do with the programming language or the tools you use regularly, but with other things that may not be technical —it can come to our minds what Heidegger wrote: “the essence of technology is by no means anything technological.”

Let me tell you a personal experience at this point. I used to work with someone with a few years of experience in web development whose main and only metric for code quality was the number of files you needed to write code to. Not security, not optimization, not code readability. Just the number of files you used to implement a feature. The less, the better. Moreover, he did not doubt to cut all the corners he could while implementing a feature so it was finished earlier. Because of that, management was happy with him: he was fast, so it was cheaper to deliver and it increased revenue for the company. Of course, no one took into account the number of bugs he had to fix, but he was fast doing it, so it only helped his reputation.

When he left the company after several years, we needed to take over his code. You can imagine it was easy to find controllers with more than 2,000 lines, containing duplicated paths and logic, without a single type or comment, exposed to SQL injection… We tried to prevent these kind of practices, but it is hard to battle non-sense using common sense. Had he used Go, C or Java, the magnitude of the disaster would have been the same — or worse. Quality is not about the programming language you use. It is about the person who writes the code: it is not that my colleague was not competent, he actually was pretty skilled. So I would say more: code quality depends on the gaze of the person who writes the code. It is about how you think about what you code, not the tools you use; the same way a good writer would write a masterpiece using a computer, a typewriter, or a pen.

We are now improving those projects a bit. In this arduous task, PHP with its environment is extremely helpful. We are implementing layered architectures using Symfony and The PHP League packages; testing where possible using PHPUnit or Behat. And we plan to integrate in our deployment quality tools such as Psalm and PHPStan. I think we have a promising future in front of us.

Before finishing, one might think that we did not answer a question that could arise from the text: “What is good programming?” But that is a hard question that we shall try to answer another day.