Let me tell you about a code review I sat through two years into my engineering career. I had written a solution that worked. I had written a solution that worked out. It changed into readable, it turned into fast, and it solved the exact trouble we had. My senior engineer looked at it and said a few words I still think about: "That's not best practice." No explanation. No alternative. Just the verdict. I rewrote it the "right" way. It was longer, harder to read, and introduced two new dependencies we didn't need. But it followed the pattern. Everyone nodded. The PR was merged. That moment stuck with me, not because I was bitter about it, but because I realized I had just witnessed something the tech industry does constantly without ever questioning it. We use "best practices" as a full stop. As an argument that ends conversations instead of starting them. And I think that's a serious problem. "Best Practice" Has Become a Shield, Not a Tool Here's what "best practice" is supposed to mean: a method that has been consistently shown to produce good results across a variety of contexts. It's supposed to be earned through evidence, iteration, and failure. a method that has been consistently shown to produce good results across a variety of contexts. Here's what it actually gets used for most of the time: to avoid justifying a decision. I've seen teams implement microservices for a product with three users because "it's best practice for scalability." I've seen junior developers get torn apart for not following SOLID principles in a 200-line internal script that no one else would ever touch. I've watched architects spend three days debating folder structure in a project where the actual architecture was a slow-motion disaster. The phrase has become a rhetorical trick. When someone says "best practice," what they often mean is: I read this somewhere authoritative, and now I don't have to think about whether it applies here. The Context Problem Nobody Talks About Here's the thing about best practices that somehow never makes it into the conversation: they are almost always context-specific. MVC works beautifully for certain applications. It becomes a cage in others. Test-driven development is transformative when you're building a public API that a hundred developers will depend on. It can slow you to a crawl when you're trying to validate whether a feature should exist at all. YAGNI. DRY. KISS. These aren't laws of nature. They're heuristics, educated guesses developed in specific contexts, by specific teams, solving specific problems. The moment we strip away that context and present them as universal truths, we've lost something important. I am not arguing that best practices are useless. I'm arguing that we've built a culture where referencing them replaces thinking about them. A good engineer asks: Does this apply here? What problem was this practice designed to solve? Is that the problem I have right now? A culture captured by cargo-cult best practices asks: Is this the approved way? Does this apply here? Where This Actually Hurts People The most visible cost is bad technical decisions. But there's a human cost too, and I don't see enough people talking about it. When "best practice" becomes the final word, it becomes a power move. It disproportionately silences junior engineers and people newer to a codebase who don't yet have the vocabulary to push back. They learn early that the way to survive is to memorize the approved patterns and stop questioning them. I was that junior engineer. I spent nearly a year doing exactly that, absorbing patterns, applying them, not asking why. And I was praised for it. It was only when I started working on a small, scrappy product with a tight deadline that I was forced to make decisions without a safety net of "best practice." Suddenly, I had to understand why things worked, not just how to do them the approved way. That pressure taught me more than the previous year of careful compliance had. The engineers who have been most valuable to work alongside aren't the ones with the most pattern references in their heads. They're the ones who can look at a situation and say: here's what I know, here's what this problem actually is, and here's what I think actually makes sense. Sometimes that aligns with established practice. Sometimes it doesn't. They can tell the difference. The Industry Loves Rules More Than It Loves Thinking I've started noticing a pattern in how engineering content gets written and shared. Articles that say "here are 7 best practices for X" get hundreds of thousands of views. Articles that say "here's when not to use X and why" get a fraction of the engagement. We have built an incentive structure that rewards the packaging of rules over the sharing of judgment. This trickles directly into how engineers learn, how they get hired, and how they get evaluated. Technical interviews frequently test whether candidates know the approved answer. Code reviews often reward compliance over cleverness. Senior engineers get status for being the authority on what the right practice is, which means their authority is threatened when someone questions the practice. I'm not naïve about why this happens. Rules are easier to teach than judgment. Rules are easier to enforce in large teams. Rules give organizations consistency. I get it. But consistency without judgment is how you end up building the right thing the wrong way, or worse, the wrong thing very, very correctly. What I Actually Want From the Industry I want engineers to say "in my experience" more often. I want more articles that start with a failure and work backward to a principle instead of starting with a principle and illustrating it with a cherry-picked success. I want code reviewers to explain the why behind every pattern they enforce, and if they can't, to consider whether they should be enforcing it. I want engineering culture to treat "I disagree with this approach and here's why" as a sign of seniority, not a red flag. Most of all, I want us to stop using "best practice" as a substitute for thinking. Use it as a starting point. Use it as a question. Ask: best for whom, in what context, solving which problem? If you can't answer those questions, you're not following a best practice. You're just following orders.

The Problem With How the Tech Industry Talks About 'Best Practices'

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Why I Write on Hacker Noon

CMT-Benchmark: A Benchmark for Condensed Matter Theory Built by Expert Researchers

3 Non-Monetary Ways To Incentivise Your Developer Team

5 Metrics Engineering Managers Can Extract from Pull Requests

7 Proven Practices to Boost Development Speed and Project Quality

Build Products, Not Projects

Why I Write on Hacker Noon

CMT-Benchmark: A Benchmark for Condensed Matter Theory Built by Expert Researchers

3 Non-Monetary Ways To Incentivise Your Developer Team

5 Metrics Engineering Managers Can Extract from Pull Requests

7 Proven Practices to Boost Development Speed and Project Quality

Build Products, Not Projects

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps