Published 2026-05-11
tag(s): #emacs #programming
I am 100% convinced that choosing the simplest solution possible is always the better choice.
My reasoning goes like this: if you approach a module/subsystem/function (the level of
granularity doesn't matter, it applies at all levels) with the most boneheaded approach
possible, your code/architecture/etc. will be stupid simple.
This might have "obvious drawbacks", but it has the undeniable advantage of being the
fastest way to get something up and running. It also has the best probability of being
bug-free, since it should be a very straightforward implementation.
Once you have something that runs, you can revisit your assumptions about these
"obvious" problems. About half the times, the real problems will not be where you
expected them, and you will be happy that you didn't jump to conclusions. Oh look at that,
I didn't need to parallelize the math of BLEH, but to focus on reading the BLAH files in
sequence, who knew
...well, not you, until you tried.
And once you start optimizing, you will be happy that you have simple pieces interacting, too.
Continuing the example from the quote, if you did parallelize something prematurely, that
complexity probably has many interactions with reading BLAH files, and you will need to
account for them, making your life more difficult in the longer run.
"But Hoagie, we know we really, really, really need to implement this as independent
micro services with 7 layers of caching". Maybe! But even then, completely replacing very
dumb and working code is still better than replacing unnecessarily complex code. And it takes
you a lot less effort.
At the very least, you should have a proven set of test cases around business logic to aid you
in v2.
I guess what I am saying, by arguing for extreme simplicity, is that it is the fastest way to
fulfill the
"build
one to throw away" adage.
(I can't believe that page is gone, I love it. Thank heavens for the wayback machine)
For example with Python code at work: Python famously has "batteries included" so there is always a standard library alternative that is, in most cases, good enough for my use case. Of course, sometimes you do need Pandas/Numpy to operate on tons of data, or a web framework, etc...but most of the times? Standard library is enough.
My Emacs configuration is still huge, but with less dependencies than ever. I really think if I will need a feature, regardless of it being an external package or custom code. I have brought back things if I noticed I missed them[1], but in general I am OK with the simpler look & feel I use now.
By applying this thinking to everything, from code I write to tools I use, I've been having a
feeling lately that my computer usage is just...too plain.
There is nothing exciting happening. My almost-B&W text editor, with no bells nor whistles,
the stuff I finish at work, using the more direct approach I can think of. All very
vanilla.
The most recent addition to my toolbox is
my Claude Code tooling, which is also
smaller in scope than other alternatives I evaluated before settling on an integration
via agent-shell.
And then I also have a feeling that I don't have much to share or teach to others around me.
Because I am not constantly looking at new frameworks, languages or libraries anymore. I
prefer "boring and proven" over anything too novel.[2]
And I love sharing knowledge!
But nowadays I don't consider anything I use or write as worthy of much attention. It's hard
to justify a 30 minute presentation to say "keep things simple".
When I talked about this to someone at work, and they suggested it was impostor syndrome.
And I used to have a lot of that, but nowadays I see myself a bit more favorably. I know that
I know my stuff, I also know that there's always more to learn.
But a big part of that knowledge I do have, steers me to the most unimaginative and simplistic
approach to software. 🤷