In the world of software and web development, adherence to "best practices"—principles such as SOLID, DRY, KISS, YAGNI, TDD, clean architecture—is often treated as moral dogma. These standards, passed down by senior architects and industry leaders, are intended to be benchmarks for code health, guiding teams toward maintainable and scalable systems.

For many web or software development teams lacking a programmer with at least 12 to 15 years of experience, especially those with only junior and mid-level developers, constructing applications or projects to these standards is challenging and fraught with uncertainties.

The search for “correction” often leads to intense debates and significant time loss. The central issue is that while we understand some principles of “good practices,” their implementation is often deeply subjective.

There’s no one-size-fits-all approach to coding. Sometimes, mid-level developers who think they’re right end up arguing and criticizing others during code reviews or meetings, creating a tense atmosphere that stifles creativity and good energy. What one developer considers “elegant composition,” another might see as “unnecessary complexity.” This kind of situation is something any tech team should avoid or overcome by developing good communication habits. When a team spends hours arguing about folder organization or refactoring plans without making any progress, it becomes a time-wasting ritual. Good programming practices are subjective because what’s “best” depends on the project’s needs, the team’s preferences, and the context. Established principles serve as guidelines, not rigid laws.

Experienced Canadian software developer Josh Comeau explains that “the real world is chaotic and nuanced. A single snippet of code can be a good idea in one context and bad in another. “Best Practices” creates the illusion of a single, universally applicable approach, but that’s not the case.”

Comeau, in fact, has a course titled “The Joy of React,” and one of his modules is called “Happy Practices.” In this module, he presents examples of standards that he believes have been beneficial for his code. In my opinion, the most significant aspect of this chapter is the author’s humble demeanor in presenting these practices. Additionally, the author emphasizes the importance of developers being open to dialogue and exploring alternative solutions in programming. This method invites everyone to bring their own ideas and viewpoints to the table.

Another critical factor to consider is context. Each project is developed based on specific requirements at a particular time, and this is where all decisions and patterns are established. It is important to recognize that changes will always occur, and some practices may need to be modified to adapt to these changes.

During my years working in a startup, I learned that each new developer who joined our team sought to apply new solutions or implementations they had learned in previous jobs. Thanks to them, I, along with other team members, gained many new and positive insights. Experience is built on humility, and there isn’t always an absolute truth in the ways of programming. The most important thing is to maintain a high degree of respect and engage in constructive conversations that foster teamwork. The best solutions emerge from teams united with strong collaboration.