My philosophy:
Best Practices.

Why best practices?

Most computer programmers follow the quickest path to solve a programming problem. My philosophy is to do it in the best possible way. Computer programs can be written in so many different ways, but the key is to look at how the creators of the framework intended it. Luckily, with Laravel, this is easy because Laravel has exceptional documentation.

To pass the Laravel Certification, I had to read the manual — it's a key requirement. Not only did I have to read it once, but many times over again. By reading by manual I instilled a discipline myself to always look for the formal documented way to solve a problem. Although strictly speaking best practice is complicated with coding, following the manual conventions means the next coder will be able to mostly follow what I have implemented in my code.

Automated testing is key

If you're the only person working on a project, then you can probably skip some automated testing. But if you're serious about steamless deployment or you're building anything of reasonable size, then automated testing is a must. I see this often, coder are "too busy" to write tests. What this leads is to brittle code and parts of your application breaking down over time. Parts that you would never have expected to break down had you not completed those pesky automated tests.

Another reason to do automated testing is discipline - to write tests is the discipline of breaking a complex problem into manageable parts.

Zero deployment issues

When working with Laravel you should never have any deployment issues. Small teams make a big mistake by deploying Laravel into environments that aren't composer and NPM friendly. If your team struggles with deploying a Laravel application, they are not using the right tools. For an extremely nominal fee one can get Laravel Forge and make deployment issues history.

Write as if you'll be replaced

Code must be clean, neat, and tidy. Don't make a mess by leaving commented code all over the show. Don't assume someone else will understand what you meant. When you rush to quickly get a piece of code out of the door, come back soon and refactor it.

Take good care of what you leave for the next person. Even if you think you have a job for life on this project, also consider what will happen if you have to move on. Be proud of what you've done as if you're showing it off to someone else. Clean readable code should still be easy readable six months from now. Always be prepared to do a proper handover and don't skimp on documentation.