The idea of Best Practice has sometimes pulled me and my teams way off course. I’m all for writing books and blogs and wikis describing “How We Do Things” but after many committments to systems and schools (or priesthoods) of practice, the “Best” label makes me nervous now. No one has gathered all the “best” opinions or best practices, and no one never will. The idea of Best Practice can unintentionally be a sort an intellectual trap in many contexts: health, fitness, genetics, self-help etc. It can lead to a sort of fallacy of universal applicability. Best? Best for what?

Everyone in tech likes to talk about how fast tech moves. I agree, and that qualifies it as an “unknown and moving problem set.” The entire world of tech gets flipped upside down every five to ten years, foundational tools become obsolete overnight, entire careers of experience are rendered irrelevant. It’s tempting to think or hope that there is a generalized set of Best Practices that can help individuals or teams or firms weather this in a way that somehow sidesteps all of the churn and disruption. In my experience no such system has survived the pace of change in tech. Tech is a partially unknown and always-moving problem set. It turns out there is no global optimum for an unknwown and moving problem set; there are only local optima.

To get anything done you have to make choices and commit to a set of techniques, toolsets or methodologies. It helps if those are somewhat self-consistent so they can be understood by the teams maintaining them, converting them, or even discarding them for something better. The trap is in being too doctrinaire about these things. In such an environment of uncertainty the way forward is necessarily messy. You are going to deal with changes you never anticipated that cut across your conceptual frameworks, your abstraction layers, your stack and your skillset.

The way to deal with this is also messy. This means mostly giving up on the project of seeking some stable canon of Best Practice and instead being comfortable with Imperfect Practice: mismatched approaches, messy codebases, half-completed migrations, competing and conflicting ideas. The kinds of things that people try to crush under dogmatic Best Practice approaches. Crazy idea: maybe these kinds of inbuilt contradictions are necessary features of systems if you want some essence of them and the people who built them to survive in some form to build the next thing or solve the next problem. Sounds crazy and gross but hear me out.

Mabye obsolescence doesn’t come from being less than perfect or by doing things “out of line with Best Practice”. Maybe in obsolescence actually can come from overcommittment to or overapplication of Best Practce (or a vendor, title, stack, product, philosophy etc). I’ve been in this industry for a minute and my brain echoes with the now-irrelevant voices of faithful adherents to some Best Practice framework or another that no one cares about now. I think a lot about the money we spent (wasted) on projects and impossible inertial pivots. I have come to think real adaptability comes from a sort of ordered disorder, where little flames of varying ideas and shapes and tools are allowed to live in people’s minds and be in play in case they need to be called upon or scaled up for a larger task. I think that’s why most tech shops look like this at some level of resolution. This type or non-uniform landscape is extremely uncomfortable for a certain mindset. If you’re in a headspace where you like to feel “done” or reach “stability”, with things arranged in perfect rows, with only allow one “best” way of doing things out of a need for cognitive simplicity, then you I imagine you would find yourself unhappy in most tech shops. Of course you might be able to find a pocket sub-industry that provides this sort of stability and comfort over some interval, but it will inevitably find itself pinched off from the main plot, rendering stale your knowledge about “how things ought to be done.” What does “proper” code review and “production quality” look like in a world of ephemeral and disposable software? How do “standard” cloud computing practices work in a world pivoting hard to data center repatriation and 50% GPU workloads? How should open source be done in a world where source IP can be ingested by an AI crawler and relaundered into someone else’s IP without violating licenses?

Whatever your set of Best Practices is, overcommitting to it can render you blind to these changes or unprepared for them by restricting your sense of the possible and a smuggled-in sense of normativity about techniques and ideas that doesn’t actually survive the kinds of sea changes that have happened and keep happening in tech. I’m still going to write down how I do things, but I also try to remember that all knowledge is provisional here, and thinking in terms of “Best” is probably going lead me astray before too long. I also think that this has biased me to lean ever more towards heavy composition over all-in-one tools. What’s an all-in-one tool not a codification of Best Practices? Even if it involves some overhead I’d rather break my platform into pieces I can easily add and remove as trends and fads come and go so I can avoid getting trapped in an all-in-one dead end that struggles to keep up with the pace and shape of the world.