Reducing overhead
/ 5 min read
Table of Contents
The forgotten folder
I recently stumbled across a folder on my computer called ‘test-rust_cli_tool’. I had no memory of building it, or what the tool actually was used for. I vaguely remember that it solved some kind of problem for me.
But when I tried to run it, it didn’t work anymore. I had forgotten the nuance about running it. I had to copy and paste it into chatGPT to get an idea of what the tool was even used for. Actually, the tool wasn’t even useful for anything anymore, it was supposed to hook into a piece of software that I no longer used.
Now the folder ‘test-rust_cli_tool’ feels like digital archaeology.
That folder: ‘test-rust_cli_tool’ is the exact reason that I am writing this blog post.
Tool Amnesia
There is a hidden cost to modern software tooling that no one talks about and that is the maintenance of memory. Not computer memory, but human memory. Learning a new tool isn’t expensive because of the first week you use it. It’s expensive because of the six months that you don’t.
Returning to piece of software that you installed 6 months ago and had forgotten all about, is tool amnesia. The onboarding process that you, yourself, have to go through twice or having to repeat a documentation search or asking ChatGPT, Claude or Gemini the same questions you already asked before. For some pieces of software and tools this seems to be a never ending cycle of learning, parking, forgetting and relearning again.
Why its getting worse
Information overload
The number of repositories on GitHub has increased exponentially. Just in 2020 to 2025 alone the number of repositories that are globally on GitHub is close to hitting 400 million!1
This is just GitHub and doesn’t include GitLab, BitBucket, Forgejo and many other open-source alternatives.
The amount of information that we have available to us is so saturated and rich that it is becoming increasingly important to be able to filter out the bad from the good. Every week there is a faster package manager, a better AI agent, a smarter wrapper, a more ergonomic abstraction.
Take Python package management: I was perfectly comfortable with pip. Now the conversation has shifted toward uv which is faster, written in Rust and a modernised version of pip.
This is progress. But progress has a cognitive cost.
Identity as a Tinkerer
Part of the problem is myself.
I enjoy trying new tools. I like seeing what’s trending this week on GitHub and install new software just to see how they feel. I optimeise workflows that were already good enough, just to try out the new shiny version of an AI agent running in the terminal. The result is still the same.
It’s still just AI running in the terminal.
But it’s a shiny new UI with more features than the tool that was released 2 weeks ago.
This curiosity leads to surface-level familiarity and instability.
Fragmented attention
Each new tool occupies mental space.
Even if I am not using the tool actively the thoughts linger:
Should I switch?
Am I falling behind?
If this the new standard?
The real scarce resource isn’t computing power. It’s uninterrupted cognitive continuity. Novelty is constantly interrupting this continuity.
A low-overhead philosophy
I’ve started to adopt a different philosophy: optimisation for durability and not novelty.
Low overhead means tools and software that don’t demand constant re-evaluation. Tools with stable mental models. Tools that degrade gracefully instead of breaking spectacularly.
I want softwarte that my future self can use without friction. Without relying on having to re-read documentation to find out the breaking-changes and to re-learn something that should really not be necessary.
If a tool requires ongoing vigilance to remain usable, the hidden mental costs are too great for me to consider hanging onto it.
Criteria for new tools
Before adopting something new, I now ask myself:
Is it worth the time investment right at this moment to learn it?
What I mean by this, is Will this tool likely still exist in five years time? Does it rely on open standards or proprietary lock-in? Am I replacing it with something that is already working?
If I can’t answer any one of these questions then I feel more at ease at tossing something into the tool graveyard. This doesn’t necessarily mean that all new things are bad, but because time is finite, I need to be more stringent with adopting new things just because “they look cool” or are the “trend”. If something new doesn’t work for me, it’s gone .
Concrete examples
Markdown has outlived countless note-taking apps. It likely will outlive the next generation too. Markdown has been around since 2004 2.
Markdown’s fundamental syntax has been around for longer than 2 decades now. And it likely means that it will stick around for a lot longer too.
I already tried to using other formats for note-taking, for exmaple, vimwiki, but this is a format that has not really been around all that long and is actually fading out. If you look at the GitHub page, as of today at least, there hasn’t been a commit in 2 years. This doesn’t mean that the format has been left in an unusable state but it means that it might not be actively maintained.
Another reason not to use ‘vimwiki’ syntax is that it isn’t an open-standard. Markdown is. Markdown is readable and recognised widely.
Another example. Simple bash scripts, stored locally, often age better than complex SaaS automation platforms with ever-changing dashboards.
Boring tools are often long-term tools.
Depth Over Novelty
When I see ‘test-rust_cli-tool’ now, I don’t feel regret.
I feel clarity.
I no longer want a hard drive full of half-remembered experiments. I want a small set of tools I understand deeply enough that future-me won’t feel like a stranger in his own system.
In a world optimised for acceleration, I’m choosing durability.
I’m no longer asking :
Is this cool?
I’m asking:
Will this still make sense when I open it in five years?
And that question has changed how I build.
Reactions
Comments
Loading comments...