there is a phrase that ends more engineering discussions than any other: "that's the best practice." it's not a technical argument. it's an appeal to authority, where the authority is an unnamed blog post, a conference talk someone attended three years ago, or the accumulated lore of a previous job. it has a specific conversational function, which is to close the discussion without addressing the particulars of the situation at hand. "but at netflix they—" is a real type of sentence that real engineers say, about choices at their four-person startup, as if the Netflix architecture was designed for their four-person startup rather than for the Netflix where it was designed.
microservices are a best practice. they are also, for a team of four without a kubernetes cluster and an SRE function and years of experience drawing service boundaries, an almost entirely negative choice that will consume engineering time and introduce distributed systems failure modes into what was previously a simple application. the best practice is real — it describes a genuinely good approach for the specific organizational scale and operational maturity level where it was developed. the problem is that the word "best" strips out the context and leaves you with an instruction that looks universal and isn't.
test-driven development has the same problem. it is a good discipline for building systems where the requirements are clear, the interfaces are stable, and the goal is correctness under known conditions. for exploratory work — you're building something and you don't yet know what it's supposed to be — it's somewhat like packing your suitcase before knowing where you're going. you'll pack the wrong things and then have to repack. the tests you write at the start of a discovery process are tests of your incorrect initial understanding, and when your understanding changes (which is the point), you'll have to throw them out. this is fine! it's not that TDD is wrong. it's that TDD is a technique with a context, and the context matters.
the honest version of "best practice" is "known tradeoffs." an ORM trades fine-grained query control for development speed and database portability — here is when that trade is worth it and here is when it isn't. mandatory code review on every PR trades throughput for defect rate and knowledge sharing — here is when that makes sense and here is when it creates a bottleneck that costs more than it saves. microservices trade deployment independence and organizational scalability for operational complexity and network overhead — here is the team size where that trade starts to make sense. these are real tradeoffs. they have real answers that depend on your specific situation. "known tradeoffs" forces you to engage with the specifics. "best practice" lets you skip them.
i'll grant one exception. when you're onboarding someone into an established codebase, "we do it this way because this is how we do it here" is legitimate and useful. consistency within a project is a genuine value; it reduces cognitive overhead for people reading the code, makes it easier to onboard new contributors, and prevents the proliferation of six different approaches to the same problem across the codebase. but that's a team convention, not a universal principle, and it's worth naming it as such. "this is our standard here because consistency matters to us" is honest. "this is best practice" implies something beyond that, and the implication is usually not true.
the engineers i trust are the ones who can explain why. not "best practice," not "that's how twitter does it," but: here are the tradeoffs, here is the context, here is why this specific choice makes sense for this specific situation. that's the actual skill. knowing the practices is table stakes. knowing when to apply them and when not to is the thing that's actually hard.