Best practice is a SIGTERM to critical thinking

The other day at work, I caught myself making a mistake I'd sworn never to make. We were discussing deployment strategies for our frontend applications, and I noticed something that bothered me: our production releases were being deployed in parallel with lower environments, rather than waiting for successful deployments in those environments first. This seemed to contradict the very purpose of having staging environments—to build confidence in our implementations before releasing them to customers. An approach that our backend deployments already followed.

I created a pull request to align the frontend with this pattern and shared it with the team. One engineer raised valid concerns about the impact on developer productivity. We had a thoughtful exchange, both making reasonable points, until I felt my patience wear just a bit thin. That's when I committed the cardinal sin, saying: "It's industry-standard best practice."

I immediately felt a deep sense of regret course through me. In that moment, I had chosen to hide behind the shield of "best practice" rather than engage critically with the situation. Rather than allowing our thought processes to run their course, I had attempted to send them a SIGTERM: a polite request to terminate.

The term "best practice" deserves scrutiny. In reality, these practices exist on a spectrum of contextual dependency. Some, like version control, are nearly universal; it's difficult to imagine a legitimate software project that wouldn't benefit from tracking changes and maintaining secure backups. In a field where everything is a trade-off, this is as close as it gets to a free lunch.

At the other end of the spectrum lie practices that are highly context-dependent. Test-driven development, for instance, sparks endless debates about its applicability across different projects and teams. As we get closer to this end, the "best" in "best practice" really starts to lose its meaning.

Beyond those few core tenets, "best practices" become a wild west of competing ideas and approaches. Each practice emerges from a specific context, shaped by particular problems and constraints. When multiple engineering teams independently arrive at similar solutions to similar problems, these approaches begin to crystallize into standards.

But this is precisely why it behooves us to resist the temptation to blindly adopt practices just because they're labeled as "industry standard." Each best practice has a birth story, a context that gave it life and meaning. Understanding this context is crucial for evaluating whether a practice fits your specific situation.

The real danger lies not in following best practices but in using them as a substitute for critical thinking. Don't adopt a practice simply because Netflix, Shopify, or Google do it. Don't hide behind "best practice", "industry-standard", or other platitudes. Don't grant yourself or others permission to disengage from thoughtful analysis. The true best practice is whatever works for your specific situation—but discovering what works requires careful consideration of your context, constraints, and goals. It demands that we engage in meaningful discussion with our colleagues, even when it's uncomfortable or challenging.

So the next time you find yourself reaching for the "best practice" shield, pause. Ask yourself: Am I using this as a shortcut to avoid deeper thinking? Am I considering the idiosyncrasies of our situation? The practices that truly matter are the ones we arrive at through careful consideration, not those we adopt by default.

Please disregard everything stated above when it comes to security.