Blindly Following Magento Best Practices? STOP NOW

Ever felt trapped by the very best practices that are supposed to be guiding you. I was once the poster child for following best practices in Magento 2. I presented about this topic at Magento Imagine in Vegas many, many years ago, and also led multiple initiatives around best practices within the many Magento dev agencies that I've worked at. But eventually, at one point, development came to a grinding halt. In this video, I'll share my experience of how blindly following every Magento coding best practice can backfire. Make sure to also stick around to the end to find out how an obsession with best practices can just go way too far, and also get some takeaways about how to prevent this from happening in the first place. Hey everyone, I'm Mark Schust and welcome to my Channel. Today I want to talk about an issue that I know many of you face as web developers trying to perfectly follow every coding best practice and standard out there that they come across. I know many of you can relate earlier in my career, I was obsessed with doing things the right way. I attended and gave talks at Magento conferences about best practices, studied courses about how to properly architect different strategies in Magento code, and of course set up all those crazy linters to make sure my coding was typed just perfectly and according to those official guidelines, down to every space, bracket, location and punctuation mark. I figured that if I architected everything properly, wrote that perfect dry code, and checked every one of those best practices boxes off the list, I'd be an awesome developer, right? Wrong. What I realized over time is that while best practices are important, taking them to extremes can hurt you in a way more than it can help. It can completely slow down your ability to ship code efficiently, grinding your development velocity to a halt. You wind up over engineering code that probably shouldn't even exist in the first place. There's a better way to do this rather than blindly following every single best practice. At the end of the day, it comes down to being very pragmatic over the code that you write. I think we all want to write solid, scalable and secure code, but that doesn't mean we should have a relentless pursuit of perfection, which causes us to lose sight of building real solutions for our clients. So let's look at some areas where I went overboard with best practices, and maybe you can relate to some of them. Learning to bend the rules even made me a bit more creative as a developer. One of the biggest areas that best practices has taken me way too far is with over engineering code. Earlier in my Magento career, I'd craft these intricate class hierarchies and complex modules believing I was creating art. You know the drill. Service contracts, repositories, DTOs, all those design principles like solid and grasp. I was a devout follower. I even went as far as building custom modules to correct third party module code. My code was beautifully decoupled but painfully overarchitected. I'd also obsess over planning for every possible edge case before writing any real logic. I told myself that this was being responsible, but at the end of the day, what it really was was premature optimization. I remember contracting for this one company where we'd have religious meetings, meetings with project managers, product managers, executives at the company and so on to discuss the ultimate architecture to build. Does this sound familiar to anyone? The process needed to be just right. Because it was to be an extremely expansive rollout. I developed what I called the Coloring playbook so the client can make updates to the spec without messing up the entire deadline. Everyone was on board. It was perfect. It was a masterpiece of architecture that was supposed to be a blueprint for success. But six months down the line the project hadn't moved an inch and I actually left the company. And a couple years later I even heard that this giant project was canceled and scrapped. All that effort, all that overthinking and over planning led to nothing. When you start over planning and overcoating things, you'll realize that unfortunately not until much later on, that about 80% of your efforts probably result in premature abstractions. Most of it will be thrown away if they're even used at all. At a certain point, all of the over planning cross over into analysis process paralysis. I get so bogged down modeling what the perfect design should be that I just spun my wheels endlessly. Now don't get me wrong, it's a good idea to have all of your ducks in a row. But you could waste so much time imagining the perfect system and what it should look like, and even more time designing it when the real implementation should probably be a hell of a lot simpler. Over engineering can happen on small levels too. I'd overthink seemingly complex UI logic that that probably could have been handled in a few lines of jquery and obsess over minor refactors rather than shipping new features. There's a point where you hit diminishing returns. So here was my key realization. Perfect is the enemy of done. When you try to architect everything to be extensible and future proof from day one, it often just leads to delays shipping the end product to customers Another area where I took best practices too far is is premature optimization. Have you ever spent hours shaving milliseconds off a database query time? I'm definitely guilty of this. The gains are super negligible, but in my mind at the time I just needed the most optimal query ever. I bet many of you have done the same. I fell into micro optimizing code in all various parts of the code base that users wouldn't even ever notice. It was an obsession to ship the most pure fast code possible on projects that no one was even using. Blindly following performance best practices can even backfire. For instance, denormalizing your database early on can often create issues down the road. Sometimes it's a good idea to just ship a RAW database table that isn't really well architected or planned at all because it's so easy to refactor it down the line. When and if you ever do actually need to optimize it, you need to know not only what to do, but exactly when to do it. Kind of like tapping the like button on this video right now. I found another wake up call when I realized that after spending weeks removing 50 milliseconds of latency on that one screen that I created that I thought would make a huge difference actually only accounted for 1% of all views in the app. All that effort for pretty much no impact. My my time would have been much better spent building out a new feature rather than optimizing code for screens that no one was even using. The key is identifying your platform's actual bottlenecks first before you decide to optimize it. Working on that wrong thing is just a waste of time and effort, you know what I mean? So now I focus on optimization. A little bit later in the development phase, when actual usage data starts to come in, I try to make the pragmatic choice for optimizing code based on real user needs, not an imagined world of an ideal speed state. The bottom line is to not let pre optimization distract you from shipping real features. Done is better than writing perfect code that never sees the light of day. Another area where I took best practices just way too far was following coding style guidelines religiously. I'm sure we've all seen developers who obsess over every bracelet, tab and comma being so precisely formatted. I was definitely one of those developers. I insisted on only using that single approved syntax. Spent way too much time debating bracket placement with team members and relentlessly linting everyone's code in the most pedantic of scenarios. I was obsessed with Magento Strict Coding Guidelines and standards Now, I fully agree that having consistent coding guidelines on your team is is important, but my insistence on perfection was just exhausting and probably very much annoying my colleagues. I ended up wasting time debating trivial style choices rather than writing new code. I was in charge of pull requests, which probably wasn't a great situation at the time. I'd hold up entire pull requests over minor white space differences, delaying entire features from even getting shipped. I know, I know. I was that guy. The bike shedding was endless. I thought it was my duty as a professional developer to get rid of anything that wasn't stylistically perfect, but over time I realized that those returns were diminishing. The endless debates over syntax and code style could just suck the life out of your team. So instead of manually enforcing perfection, I learned to leverage tools like Linters, and there are even AI code reviewers to automatically check style today. This frees up your time to focus on real code quality, such as architectural concerns, not superficial syntax choices. For example, you can integrate a Linter into a CI pipeline to detect Magento coding standard violations, which automatically checks new code for stylistic issues before the pull requests are even reviewed. Today, an AI assistant can scan pull requests and easily alert the coder who made the request with any major discrepancies before it ever hits the review stage. This helps to keep code quality high, but without the manual toil of every developer hand checking styling concerns. And you can easily configure Linter rules to only fail builds on major violations, not trivial spacing differences. There are times it may even make sense to push through that imperfect code, especially if it doesn't break anything in your existing builds. Then you can simply create a ticket for the developer who created it to come back and revisit that code in the future. This keeps you shipping code without worrying about trivial coding standards that may not even be improving your code base. This is a win win for enforcing consistency without pointless blank shedding. The main takeaway is to focus your efforts on code quality and architectural decisions that actually move the needle, not superficial syntax choices. Leverage tools to check style automatically and draw the line when formatting debates start to seriously kill your developer productivity and happiness. And if you want to know about some other tools that can really supercharge your Magento 2 development workflow, you won't want to miss this next video for some game changing tips and tricks. And until next time, keep coding.