Of the three hard problems in computer science, the one I probably spend the most time on is “naming things”. (Off-by-one errors are too often the bane of my programming existence though.) And sometimes, I get push-back or eye rolls on how it’s not worth spending any time on the name. “Let’s just pick one at random and move on”.
This is usually the argument of someone who doesn’t believe in, or care about The Thing’s future. Think about the times when everyone obsesses over choosing a name: when it’s for their kid, or their pet, or their startup. To a lesser degree, their project or their social media handle. Stuff that has a real future for them and they know will likely and hopefully be used for years and come to be shorthand for something near and dear to them.
So when someone rushes through the name of a Python module or a wiki page or a feature, it often means that they don’t think it’ll matter: be it because it won’t last, or because no one will come across it again, or even that just they won’t. In their mind, there’s no future in which This Page will need to come up in Confluence search results, or in which Dave the Python dev will need to quickly understand what a variable called “idx” does.
But this is not an article about naming things — though, I’d be shocked if I don’t write that one someday. It’s about the more general problem of failing to recognize the importance of some of the “small” stuff, like the names of things which may be typed and spoken and searched by untold masses for years to come. Of course, there are a lot of small things that are unimportant; things that can be safely overlooked or bypassed or pushed off ad infinitum, because they don’t really have downsides. Things like learning Italian, diagramming your codebase in UML, or showing up to your 1:1s. Okay calm down — yes, that last one was a trick.
But some very important things are deceivingly small. Like honey bees and gut bacteria. Or out of sight, like the type of insulation in your house, which will make a difference in your HVAC bill in the tens of thousands of dollars over its lifetime. Or the lack of automated testing / CI/CD / code formatting / linting which will make that same difference in dramatically less time. Or skimping on offsites for remote teams. Under-funding the development of developer tools. Not prioritizing documentation. Not doing interview training. Not writing a Slack culture guide. Skipping 1:1s.
There are a lot of these small things that have outsized effects: the individual effort is small, but the cumulative results are big. Just like compounding interest, a tiny seed, or that domino trick above. Conversely, not doing them can lead to death by a thousand paper cuts. Or if not death, at least an increasing leak of money. One example from the wild I often think about is how iOS updates are (now) fairly seamless and how much money that investment probably saves: because it encourages people to upgrade quickly, Apple can avoid wasting thousands and thousands of hours per year on supporting a large fleet of outdated devices.
And while it’s tempting to keep going with a list of these items like above, the reality is that the list depends a lot on the circumstances: the age of the company, the size, the culture, the tech stack, etc. There’s no one list to rule them all, as far as I can tell. The closest it comes to is that a lot of this mighty small stuff falls under “enablement” — but that’s a broad term for a lot of things. So it becomes yet another one of those aspects of leadership that’s ambiguous and requires judgement calls based on experience of what’s important in concrete terms, right here and right now and with this group of people. And some of that important stuff will be the seeds that makes the organization 10x more efficient.
Unfortunately, the bigger problem is what comes next: you’ve recognized what needs gardening, but now you need to convince everyone else of the value. If not done well, this attempt at persuasion can cause problems ranging from politely being chuckled off the virtual podium, to getting a stern talking to about wasting your time on trifles. “Can’t you see the backend is crashing twice a week? And you’re talking to us about automated tests? We already have QA.” This is why most people don’t even bother taking up the mantle and arguing for the small stuff.
It’s hard to persuade others to spend time gardening when the roof is leaking — and there’s potentially a lot to lose in trying. But it’ll be a worse situation when the roof is inevitably fixed, and the garden is devoid of food. Depending on what time period this poor house is in, a forgotten garden might mean starvation, or it might mean living on pizza and Mountain Dew for years until the heart disease kicks in, or it might mean leaking money on buying produce. None great things.
So spend time on the argument. Learn to become persuasive. Learn what kinds of arguments work on different stakeholders. Become great at crafting a powerful narrative that can change minds. And leverage that for good. In a way, this is smallest and mightiest of all the things.
Thaw with her gentle persuasion is more powerful than Thor with his hammer. The one melts, the other breaks into pieces.
– Henry David Thoreau