It's funny how from the outside, IT is often seen as an exact science. When starting as a developer, I often heard people say: "Oh, you're in IT, so you must be good at mathematics". I never understood why someone who is supposedly good at mathematics is the right person to fix a printer.

When you have some experience building applications, you know that IT is not an exact science. There are multiple valid solutions to a problem. Take five developers and ask them what the best way to set up a blog is. You'll likely get five different answers. Each suggestion will have its own set of tradeoffs.

On a lower level, many interesting choices need to be made that don't have a clear cut answer:

• Can we send a mail from a controller?
• How should this concept be named?
• Where should this piece of logic be saved?
• Should a class be made final?

There are no clear cut answers for these questions. It depends on a couple of things: the size of the project, the preference of individual team members, and the agreements that the team made.

Programmers have particular preferences on how things should be handled. Some prefer to work very strictly by sticking very close to the SOLID rules. Others tend to work more pragmatically. Most devs are not in one camp or the other. I see this as a scale.

There are different kinds of preferences as well. Some consider visual debt. Others don't care about that. Some might want to stick to the default structure of their favorite frameworks. Others like to use a custom organization.

There's no approach that is inherently right or wrong. Beautiful, maintainable projects can be built either more pragmatically, or very strictly. Most projects, however, are not built or maintained by a single person. Instead, there is a collection of people involved, who are all on different positions on the strict/pragmatic scale.

From experience, I can tell you that it's not a good idea to let each member use his or her preferred style on a project. You'll likely get a project that isn't programmed consistently, making it hard to add features or perform maintenance.

In a well-oiled team, members talk and discuss the pros and cons of each of their individual preferences. When reaching a consensus, it's a good idea to write it down, together with the reasons why a certain approach was picked. This can result in a set of guidelines that newcomers to the project or team can refer to. You can read our collection of guidelines on our website. It contains our agreements on details, such as how to name things, and to use certain Laravel features.

Our Laravel Beyond CRUD book + video course is an extension of these guidelines. In the book / video's you'll learn how our team organizes larger than average projects. The knowledge in this book is the result of countless discussions between all team members. Our team has built and is building multiple large projects. By creating and maintaining these projects, we have discovered where it's safe to be pragmatic and where it's often best to stick to a strict approach.

We consider our guidelines and this book a living document. People, teams, and opinions change over time. Don't dogmatically keep following rules you agreed on in the past, but keep challenging them. New experiences should lead to new and improved agreements.

Instead of blindly following the ideas shared in the book, I encourage you to discuss the content with your colleagues. Maybe your team members are positioned somewhere else on the pragmatic/strict scale, and the agreements you make with your team should reflect that.

I'm sure that everyone some cool things by reading/watching Laravel Beyond CRUD that can help you and your team build better projects.

At the moment of writing there's an introductory offer, so you can purchase your copy with a nice discount.