9 Laravel Experts Share Most Annoying Development Mistakes

Posted on
9 Laravel Experts Share Most Annoying Development Mistakes

Laravel is the most starred PHP Framework on Github, powering over 37,794 websites on the internet. Sadly, a good number of these websites were built by half baked developers  – owning to ease of use of the Laravel framework.

The best programmers are up to 28 times better than the worst programmers. – Robert. L. Glass

Having gone through several projects on github, following the core principles of Laravel development in every project possible, one can easily differentiate a great developer from the regular guy; those who write spaghetti code from the really good guys. For some developers, it’s about getting the project done as quick as possible, while for others, it’s usually trial-and-error which in most cases, leads to mistakes that becomes an integral part of the project.

To understand these mistakes, we reached out to prominent Laravel experts across the world such as Graham Campbell, Prosper Otemuyiwa, Dries Vints, Mark TopperVincent TalbotJacob Bennett, James Brooks, Ajeh Emeke, and Alex Bowers – with the question “What ONE Laravel development mistake drives you crazy?”. Drawing on the experience and skills of these experts, we present you 8 Laravel mistakes that annoy most experts.

Bad code coupling to the Config method.

Graham Campbell – Laravel Contributor, StyleCI, Student (My views are my own, and are not that of Taylor Otwell, Laravel, or Alt Three Services Limited)

I see this all the time in laravel packages. They randomly call the global config function, without knowing if it even exists, or caring about the code coupling. The ONLY way you can call “config” is if you’ve actually got laravel/framework as a dependency.

The use of Fat Models & Controllers.

Prosper Otemuyiwa – Technical Writer, Auth0 Inc 

Abstraction is key. Tons of business logic should be moved to service classes rather than piling them up in your models and controllers.



Dries Vints – Lead Developer, BeatSwitch

Keep Eloquent/ORM logic inside models/services instead of controllers.

 Writing program logic in blades



Ajeh Emeke – Software developer at Codulab

Doing this:

@if(Auth::user()->role == 'admin')

which could have just been embedded inside a model as a custom method to become this:


I try to make sure every logic stays in the controllers. For the later, it’s a lot easier to change the admin detection criteria across the application by simply tweaking the isAdmin method in the model rather than looking for every occurrence of ‘admin’.

Inadequate unit testing


Mark Topper – Creator of Ulties Solutions

The one thing that makes me most crazy is the amount of Laravel based projects out there WITHOUT any form for unit testing to ensure it is working. Laravel comes with a simple solution for building small but yet powerful tests without much knowledge of the PHPUnit system; with just the basic Laravel understanding anyone should be able to make unit tests for their Laravel projects. Sadly what makes me crazy, is that it is not always done! 

Unnecessarily formatting database Fields


Vincent Talbot – Senior Web Developer, Libéo

Trying to re-implement the magic of Laravel because they don’t believe in it (Getter/Setter for each properties in the models).

Failure to validate user input


Jacob Bennett – Co-host of the North Meets South Web Podcast and Laravel News Podcast

Failing to validate user input is a big one. Many new developers assume that the values in their front-end forms are the only values that could be sent through to their application. Thankfully Laravel makes this laughably easy these days thanks to FormRequests and the use of `$this->validate()` in your controllers.”

Improper implementation of queue jobs scheduling

Alex Bowers – Software Engineer at Shopblocks

 The use of scheduling in a clustered setup often leads to duplicated jobs. Most developers do not have a clustered development environment and so do not notice or expect this. It is trivial to counteract.
Make use of your cache to store a mutex on each of the scheduled tasks. This way you can guarantee that the job will only be queued once, regardless of how many servers your application utilizes.

Not reading the source code


James Brooks – Lead Developer, Blue Bay Travel

Not reading the source code! You’ll find so many interesting snippets in there.


We went to great lengths to identify and reach out to these elite programmers so we could gather what actually bugs people on a daily basis. Sadly, some of the above mistakes appears to be painstakingly obvious; the question is why do developers still make them? A simple answer perhaps, can be that they became too integrated with these practices hence, not willing to unlearn. Not too good.

Don’t ever get used to bad practices. Do your best to deliver and demand the best development practices possible. Do it for yourself and for others who might work on the projects in the future.