There is a particular conversation that has been happening in software for forty years. A senior engineer has shipped something that works. A more recent arrival points out that it does not follow Best Practice X, where X varies with the decade — TDD, microservices, hexagonal architecture, monorepos, polyrepos, GraphQL, CQRS, event sourcing, dependency injection, trunk-based development.
Sometimes the senior engineer is wrong and just defending what they already built. Sometimes the junior is wrong and is parroting advice that was written for a context they have never worked in. Telling the difference is one of the more important skills you build over a career.
A best practice is a context-stripped decision.
Every best practice started life as a real decision someone made for a real reason in a real context. Microservices made sense at Amazon-scale. TDD made sense for teams writing safety-critical code. Event sourcing made sense for systems with complex audit requirements. The decisions were good. The contexts were specific.
When the decision becomes a best practice, the context gets stripped out. What remains is the rule. The rule travels into your codebase without any of the conditions that made it a good idea originally. Often, the conditions that made it a good idea do not apply to your situation, and the rule actively hurts you.
“Every best practice started life as a real decision someone made for a real reason in a real context. The context gets stripped, the rule remains, and the rule travels.”
When to follow a best practice.
Follow it when you can articulate the original context, recognise it in your situation, and accept the trade-offs the practice was designed to manage.
Use TDD if you are writing code where the cost of regressions is high and the requirements are stable enough to be expressed as tests. Use microservices if your team is large enough that the coordination cost of a monolith genuinely exceeds the operational cost of distributed systems. Use CQRS if your reads and writes have genuinely different scaling profiles.
In each case, the test is the same: do the conditions that justified the practice exist in your situation? If yes, the practice is a good shortcut to a known-good decision. If no, you are paying the cost of the practice without any of the benefit.
When to ignore a best practice.
Ignore it when the context that justified it does not apply to you. Ignore it when the cost of following it exceeds the cost of the problem it was designed to prevent. Ignore it when it is being applied as cargo cult — “real engineers do this” — rather than as a deliberate choice.
A solo engineer building an internal platform for fifty users does not need microservices. A monolith with clean module boundaries is the right call, and the moment you split it into services you have multiplied the operational cost without buying anything.
A small team building a B2B SaaS does not need to write tests for every line of code. They need tests on the parts where regressions are expensive and the rest can be tested when it stabilises. Strict 100% coverage is a productivity ceiling for early-stage software.
A two-person startup does not need a polyrepo with three CI pipelines and a dependency graph. They need a single monorepo, a single deploy, and the cognitive bandwidth back.
- →Best practice = a context-specific decision dressed as a universal rule
- →Always ask: what context produced this? Does that context apply to me?
- →If yes — follow it as a shortcut to a known-good decision
- →If no — you are paying the cost without the benefit
How to talk about it.
When somebody pushes a best practice at you, the right response is not defensive. It is curious. “What problem does that solve, in our context?” If they have an answer, you can have a real conversation. If they do not, you have surfaced the cargo cult, gently, and you can both move on.
On the other side: if you are the one pushing a best practice, do the work to articulate the context. “We should add CI checks on every PR because we have shipped two regressions in the last quarter and our deployment is fast enough that the lag does not matter.” That is a real argument. “CI on every PR is best practice” is not.
The patterns I do follow, almost always.
Some practices have survived enough context-stripping that they are nearly universal. Source control on everything. Automated deploys. Real environments — dev, staging, production. Real backups, tested. Documented setup steps that a new engineer can follow in an afternoon. Logging and error tracking on production code.
These are not best practices because somebody declared them. They are best practices because the cost of skipping them, in any context, vastly exceeds the cost of doing them. That is the actual test for whether something is a real practice or fashion.
“A real best practice survives context-stripping because the cost of skipping it, in any context, vastly exceeds the cost of doing it.”