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

For many software development teams that lack a programmer with 12 to 15 years of experience — especially teams composed primarily of junior and mid-level developers — building applications according to these standards can be challenging and filled with uncertainty. The difficulty is not necessarily a lack of technical skill, but the ambiguity involved in deciding which practices should be applied, when they should be applied, and to what extent.

The search for the “correct” solution often leads to intense debates and significant time loss. Although we understand many principles associated with “good practices,” their implementation is deeply context-dependent. What works exceptionally well in one project may become unnecessary complexity in another.

There is no one-size-fits-all approach to coding. A practice that benefits a large-scale financial system may be excessive for an internal startup tool. Test-driven development might improve reliability in mission-critical software while slowing down experimentation in an early prototype. Likewise, a microservice architecture may support scalability for a large organization but create operational chaos for a small team.

This does not mean that best practices are meaningless or purely based on personal opinion. Engineering principles remain valuable because they provide teams with a shared vocabulary, proven patterns, and a foundation for maintainability. However, applying them effectively requires judgment rather than blind adherence.

In many teams, especially those without highly experienced technical leadership, disagreements about architecture or code organization can evolve into ideological conflicts. Mid-level developers who strongly believe in a particular approach may criticize alternative solutions during code reviews or meetings, creating a tense atmosphere that stifles creativity and collaboration. What one developer considers “elegant composition,” another may see as “unnecessary abstraction.”

This is the kind of situation that healthy engineering cultures should avoid — or learn to overcome through respectful communication habits. When teams spend hours arguing about folder organization, naming conventions, or refactoring strategies without making meaningful progress, the process risks becoming a performative ritual rather than productive engineering work. In some cases, developers defend patterns not because they solve concrete problems, but because those patterns are associated with seniority or technical prestige.

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 a bad idea in another. ‘Best Practices’ creates the illusion of a single, universally applicable approach, but that’s not the case.”

Comeau also created a course titled The Joy of React, which includes a module called “Happy Practices.” In this module, he presents examples of standards and patterns that he personally found beneficial in his work. The most important aspect of this approach is the humility with which these practices are presented. Rather than treating patterns as absolute truths, he encourages developers to remain open to dialogue, experimentation, and alternative perspectives.

That mindset is essential because software development is shaped by context. Every project is created according to specific business requirements, technical constraints, deadlines, and team dynamics. Architectural decisions are made within a particular moment in time, and those decisions may need to evolve as the product, company, or technology changes.

During my years working at a startup, I learned that every new developer who joined the team brought different implementation ideas and experiences from previous workplaces. Many of these perspectives challenged our assumptions and introduced valuable improvements. Through those interactions, I realized that technical growth is often less about defending certainty and more about developing the humility to continuously learn from others.

Experience in software engineering is not simply the accumulation of technical knowledge or familiarity with design patterns. Truly experienced developers understand trade-offs. They know when to prioritize simplicity over abstraction, delivery over perfection, and collaboration over ego. They recognize that maintaining a healthy and respectful team environment is often just as important as writing elegant code.

There is rarely an absolute truth in programming. The strongest solutions usually emerge not from rigid adherence to ideology, but from teams capable of constructive discussion, adaptability, and mutual respect. Great software is ultimately built by teams that collaborate well together — not by teams obsessed with proving who is technically right.