Best practices, they are not as important as you think they are. They do not just apply to the code you write to get your app to work. They also apply to styling, they apply to testing. You can implement best practices in a multitude of ways into your app, but should you?
Please support my original publication here:
Best Practices Are Not As Important As You Think They Are
What Best Practices Achieve
The main purpose best practices serve is code quality. You want maintainable code that you can always go back to, understand what it does, and easily swap out. Good practices make communicating with other developers way easier if you all have a certain standard, a code quality that you can all refer to. That is especially useful if you work in teams. If you work solo, not as much, but it still helps in some cases.
Risk is minimized when people agree on how to write code. If you miscommunicate with other developers about coding style or patterns, it can be really annoying. It leads to merge conflicts and that is a lot of wasted time for everybody involved. So why not set certain best practices to implement into your project, whether you work with other developers or by yourself, to avoid all that?
Why Context Matters
Well, it is true that conventions can reduce friction. But from my experience across interactions with beginners, intermediates, and senior-level pro coders, the approaches to best practices vary wildly. The main difference between beginners and senior or more advanced programmers is that their understanding of what a best practice is fundamentally different.
Advanced programmers understand why these best practices exist. That understanding allows them to step outside of them willingly when justified by innovation. Stepping out of best practices is not uncommon, and sometimes it is not bad at all. The important thing to understand here is context and the reason you are applying a best practice in the first place. What does it do for you?
Mindlessly copying best practices from projects you see, without understanding why, rarely makes sense. It might impress an employer who only glances at your code, but when they then ask why you chose to go this way or that way, you will not be able to explain it. Best practices exist to solve certain problems in usually efficient ways. If that underlying problem does not apply to you, then implementing that best practice is of no value.
Advice for beginners: Just Write, Then Refactor
What I also see a lot with beginners is anxiety over whether their code follows best practices. I totally understand why you want to write good, maintainable code, especially if you are looking for a job and want a GitHub that shows professionalism. But this striving for best practices often hinders productivity and writing code.
My advice to beginners is, just write. Write whatever comes to mind getting the job done and then refactor. Implement best practices as much as you want once the app actually works.
Wanting to implement best coding practices from the start is an absolute recipe for disaster and unproductivity if you are not working in an enterprise context. If you are not building within tight team constraints, do not worry so much. It is not as important as you think.
One exception: Security
There is one area I want to exclude from this relaxed approach, to security. Security best practices absolutely make sense to adopt early because sloppy choices when handling user data can be catastrophic. For authentication, sessions, JSON Web Tokens, password handling, and similar concerns, follow established and well-documented approaches. You can look at other people’s implementations and learn, then copy the reliable parts into your app while understanding what is happening. Security is well documented for a reason. Treat it seriously.
Common Pitfalls: Premature Optimization and Scaling
Besides security, do not obsess. The most common cases of over-worrying about best practices are over-optimization and premature scaling. People worry about how well their app will scale if they have zero users. They fret about supporting tens of thousands or millions of users before they have any. That is beyond reasonable.
Just build. Once you have users and the revenue that supports investments in architecture, then you can worry about performance upgrades and scaling. Worrying about those things now will hinder your progress.
Concrete Example: File Names
A concrete example that often comes up is file naming. People tell beginners that you cannot name your components anything other than what is established. I am not sure of the exact name for the convention, maybe PascalCase or camelCase, but the idea is that the first letter of each word in a component name is uppercase, and the rest is lowercase. That is a convention, a best practice you are totally free to break.
Why does that convention exist? It exists to differentiate between regular files and components. If you search for files, it makes things a bit easier. It looks cleaner in imports, and you can tell right away. If you are not familiar with React, you probably have something similar in the tech you use. But after you understand why the convention exists, if you are working alone or in a project where another convention applies, who cares about breaking it? If the file names are readable, name them in PascalCase, name them with hyphens, whatever works for you.
How to Apply Best Practices in Teams vs Solo
To summarize in one sentence, there is too much should in the community and too little could. Use best practices as tools rather than rigid rules you must follow. They are there to help solve problems, not to be worshiped blindly.
If you are a beginner, focus on getting things done, then refactor. If you work in teams or in the enterprise, adopt conventions that reduce friction. Always treat security as a non-negotiable area for existing best practices. And remember, the context you are in should determine how strictly you apply any given rule.
Summary and Final Thoughts
I would love to hear your thoughts. How do you weigh best practices against shipping features? What trade-offs have you made that paid off? Share your experiences and let us keep this conversation practical and useful.
Closing
That is it for me. I will see you in the next one. Have a good one and bye bye.
Found something valuable in this article?
Show some support, it truly means a lot.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.
Top comments (2)
Every project has its own reality, and sometimes adapting, experimenting, or even breaking the “rules” leads to better outcomes.
Stay practical instead of rigid