I’ve been programming with PHP for around 7 years. In that time I’ve discovered frameworks and libraries; entire ecosystems around content management platforms; and a wide community of other PHP programmers all choosing to use, or not to use, the same tools that I use. A good proportion of these other programmers have become real friends and, judging by the keynotes at the majority of conferences I’ve been to, I’m not alone in believing that together we can help each other learn and grow, build better software, and collectively assist those around us in taking the next steps in their careers. PHP as a language has been lampooned, laughed at, denigrated, criticised, and sneered at by ‘proper’ programmers who often see our language of choice as nothing more than a mess and who see those of us using PHP as a collection of amateurs (I’d suggest that these people may have had a point in the past, but are now arguing from a position of ignorance, especially as PHP 7 has done so much to help make PHP a more mature language). Yet still PHP continues unfazed and the community toughens its skin and continues to build new products, libraries, tools, and features. But the PHP community is broken. There are clear factions of die-hard fans within our wider ecosystem viciously guarding their own biases and making the same denigrating and sneering comments we already face from the much wider software community. There are also examples of people’s personal lives being ruthlessly exposed to the world by their peers to embarrass and discredit them, and discussions being made public which should have been kept private; regarding whether those aspects of their personal lives have a negative effect on others. I’m not a member of the sub-community this second issue revolves around, so I will not explore it in this article. However, I am a member of the wider PHP community encompassing everybody involved and therefore I regard a problem with a smaller faction within PHP as a problem with the PHP world itself. It’s only natural that frictions within sub-communities percolate through to wider audiences, as people are rarely involved with just one project, and so their opinions, views, comments, etc are communicated to those not directly involved. Of course the issue affecting the most people, whether directly or indirectly, is the escalating friction between proponents of the Laravel and Symfony frameworks, and the Doctrine ORM. In the same way that those programmers who choose to learn and use other languages look down upon us PHP developers, many Symfony / Doctrine aficionados make the same disparaging remarks about Laravel. In response, Laravel advocates seemingly become increasingly antagonised and have a tendency to react aggressively to criticism (whether constructive or otherwise). It’s easy to understand how a sub-community can become siloed in such circumstances, and how subsequently that same sub-community can easily misinterpret every mild criticism as a full-on attack on their methods. I’m sure almost all of us who’ve been in programming for some time have had our code criticised at some point. Criticism varies from ‘WTF is this shit?’ to ‘you should try to apply the SOLID principles / [ design pattern] here, it will save you time & frustration later on’. How you give and receive criticism lays the foundation for how you grow as a professional and how you are perceived by those around you. Perhaps most importantly for community leaders, it defines how those who follow and respect you act toward their peers. x Now we have senior programmers, community elders, project leaders, and role models engaging in public spats over platforms such as Twitter and Reddit. We see passive-aggressive comments regarding the scalability of projects in Framework , or how many lines of code library ’s core methods contain. This serves to achieve nothing but convince the people reading these threads that they are justified in avoiding the framework / tool with the opposing view, and that their choice is definitely the correct one. x y In short, by perpetuating these arguments we are robbing less experienced developers of the chance to experiment and experience other approaches to common solutions. We are denying them the ability to openly express themselves and discuss the benefits and pitfalls of each framework without fear of ridicule from those around them. We are preventing them from evaluating and learning how to select the right tool for the job. We are steadily blocking their career progression. This is harmful to them, and to us as an ecosystem of PHP developers. It acts as yet another barrier to new developers picking up the PHP shovel and beginning to learn how to create web applications with it. Considering the negative image many young programmers already have of PHP, we certainly don’t need yet more barriers to entry. I’m ashamed to say I have been part of this too. It’s very easy to follow the trend when those around you are doing the same, in a collective wave of mutual superiority. At a Symfony meetup in London somebody mentioned Laravel in some context, and a surge of laughter made its way around the room. I hadn’t thought any more of it until the next day when a new attendee commented that they had felt isolated by our behaviour. Cue the moment of realisation that suddenly our small club of Symfony fans had dropped the ball and made somebody feel unwelcome, and I had contributed to that. See more: . https://www.meetup.com/symfony/events/229755129/ I spoke to very briefly after the Symfony Live London conference about my concerns with the way our community is dividing itself (disclaimer: Symfony is my preferred framework, but I have worked professionally with both Laravel [v4 & 5] and Zend). I won’t dig too deeply into Fabien’s response for a couple of reasons. Firstly, I would be inferring a lot and I would do an injustice to him if I were to attempt to second-guess his thoughts, and secondly he told me he was also planning to write an article on the same subject. However, he did tell me that he faced a lot of criticism with Symfony 1.x when developers were comparing it to Zend at the time. Fabien Potencier Symfony 1, for those who are not old enough to remember it, used Doctrine 1 and its implementation of the ActiveRecord pattern, included a lot of extras by default, and made it phenomenally easy to couple your business logic to the framework. It was an opinionated framework which laid out the tools it expected you to use in front of you, and let you get on with the job quickly. Symfony 2 began to change all of that. Developers using Symfony wanted more choice and flexibility when choosing their tools and what to include in their projects. They wanted easier inclusion of other libraries and the ability to swap those libraries easily if the original solution proved to no longer serves its purpose. In essence Symfony evolved very quickly between versions 1 and 2 to be something different to what it was originally. It moved from an opinionated framework with all tools packaged within and a certain level of naivety toward interoperability with packages outside of the Symfony. Symfony has gone a long way to transform itself into a set of reusable packages and components, and incorporating PHP-FIG’s recommendations means the components could be easily included in other frameworks, libraries, and CMS systems. Symfony developers are rightly very proud of what the framework has achieved and are eager to share how they’ve done it. The majority of developers I have spoken to agree with me that they find Laravel’s documentation more accessible than Symfony’s, and that the framework is far easier to get started with. Laravel is more opinionated than Symfony is these days, so documentation can be less abstract and subsequently more direct on how to achieve a goal with the tools provided. There is a strong tendency to label Laravel as a beginner’s framework, or as a tool for RAD (rapid application development / prototyping) only, and that it shouldn’t be used for more complex projects. The reaction from Laravel users, of course, is to then respond with “well, it was used on site so STFU”. Doctrine users retort with “we dropped ActiveRecord ages ago, your ORM sucks”, and everybody else chips in with “facades, really?” in a classic playground “my dad’s bigger than yours” back-and-forth. x Personally my one real gripe with Laravel and Eloquent is that it takes extra effort to add foreign keys and indexes on the database. I believe this should be high on the priorities list when designing a data structure. I have inherited multiple Laravel projects produced by different companies, none of which have had a single foreign key or index in them. Of course this leads to loss of data integrity as well as performance problems. I also feel that Laravel and much of the training resources around it encourages the user to couple their code tightly to the framework. A previous company I worked for saw one developer spend months working on what should have been a simple upgrade from Laravel 4 to Laravel 5. He spent his time copying and re-writing files and files of logic placed in the controllers. If the code had been decoupled, the company would have spent a lot less money on the upgrade, and he could have moved onto new feature development much sooner. In my opinion Laravel can be used for large scale applications as its advocates claim, but unless developers are experienced enough to know what they’re looking for in the documentation in order to allow the application to scale, they probably aren’t going to come across it. Admittedly it’s just as easy to couple your code to Symfony controllers, but it appears to me that the Symfony community has a greater base-level of awareness regarding why doing so is a bad idea. I don’t think I’ve ever seen a single instance of a Symfony user ridiculing the idea of decoupling code but I can think of several instances where I’ve seen Laravel users mocking the practice. Perhaps these are users who are experienced enough to know about decoupling and that it doesn’t fit in the scope of their current project, or just maybe they’re junior developers who are riding that same wave of groupthink I mentioned earlier, who will be turned off giving it a shot because their community leaders don’t think it’s such a great idea. This spun-off debate over decoupling is just a symptom of a far deeper problem, however, and the real issue is that as developers we make our choices as to our favourite tools and align ourselves with others who have solved the same problems in the same ways. By restricting ourselves to constantly using what we know, and by immersing ourselves into social circles with others who have the same thoughts and ideas, we limit the coding gene pool. Using our own golden hammers we forge shackles which may very well limit our own career paths ( ). Just because we solved something in one way doesn’t necessarily mean someone else’s approach is any better or worse, it’s just different. https://sourcemaking.com/antipatterns/golden-hammer What’s most concerning to me is the effect we potentially have on the choices less-experienced developers make. We all feel a sense of satisfaction when we make a personal recommendation to somebody and then see them follow our footsteps. However what we shouldn’t be doing is encouraging younger developers to not bother trying or because of our own biases. What’s the difference between that and telling somebody not to program in PHP at all? x y We’re toxifying the environment and making it harder for people to learn, experiment, play, and develop. We should be giving advice based upon our experience, and helping people to try out other solutions. Watch how the people you follow give and receive criticism. Ask yourself “Is this the kind of feedback which contributes positively to the community? Is this the kind of person I should be taking examples from?”. As a community leader, ask yourself “Am I fixing my own shackles onto the legs of those around me? Have I had a negative effect on somebody else through my own choices?” Reactionary flame wars and ill feeling does nothing to promote our collective cause, and all we’re doing right now is turning people off becoming members of our global programming community.
