For a while, I was using KDE. The configurability was pretty great.
Now I'm using Cinnamon. It's just a little bit more standard, and has just a little less to tweak.
On a lot of my software projects, I haven't been removing many features, but I sure have been removing non-standard things and reinvented wheels.
I was using FVWM in a custom Pi Distro, partly because PIXEL gave me issues on a read
only environment. Moving to FVWM got the project working fast, but I've since resolved those issues. The reason for the divergence from the default no longer applies, so I have returned to PIXEL.
Sometimes, the stock solution doesn't work, or we don't have time to learn it, forcing us to quickly hack something together.
But that doesn't mean we should stick with our fragmented, scratch built stuff forever.
It's easy to think with the sunk-cost fallacy and keep maintaining custom stuff,
when the standard issue would only take a little effort to switch to.
This site used to be on Hubzillla, and for a long time, I didn't want to switch away,
because of the effort. But as it turned out, going to the more standard DokuWiki was not
too hard, and was a chance to tidy up a bit too.
I hate minimalist software that requires the user to understand and control every detail of the machine. I don't like programming in C. I have no interest in doing the computer's job for it.
But one time I DO like to get rid of code, is when it's unusual, custom, one-off code. Why? Because that code has *weight*.
Perceived weight, that feeling of being dragged down by software, doesn't always mean the software uses a lot of CPU. Sometimes the burden is on the user, or the developer, not the computer.
If I write an application, I want every bit of effort to go directly to making that application better, in a direct, user accessible way. But if I reinvent the wheel, use some guys brand new language, or something like that, then a lot of my effort just goes to maintaining the infrastructure.
Every custom thing I build, I have to maintain until I throw it away. If I don't want my life bogged down by config files and broken Arch packages, I have to be careful not to build, and especially not to get dependant on, anything that doesn't provide real value.
Sometimes people do this for educational reasons. But doing this on a real project is like wearing ankle weights when you're just trying to get things done.
Some things pretend to make life easier, but they really don't. If your home automation
solution is going to result in someone getting annoyed when someone accidentally uses a the manual
light switch, I want nothing to do with it.
I'm not going to spend a month setting up a solution to a task I do once a month, that takes ten minutes.
And I'm certainly not going to use some terrible pseudo-assistant doing things like automatically
running backups when I plug in a hard drive, when it has no way to tell whether I even meant to plug in that drive.
Systems like that are about as helpful someone giving me the world's most boring math textbook
for Christmas, complete with a passive-aggressive note. It's less of a nice gesture, and more of an extra obligation.
One programming principle we rarely see outside of UI is the Principle of Least Surprise.
If users don't want to be surprised by unpredictable and non-standard behavior, why would programmers?
These days, when looking for ways to improve something, especially a small personal project,
I ask “What have I been doing differently from everyone else, and is it time to stop?”.
I don't believe that perfection is achieved when there is nothing left to take away. Usually,
taking things away just puts them somewhere else, generally on the users lap.
Nobody wants code to be more complicated than it needs to be, but it's ultimately just
a heuristic, and simplicity isn't the only metric that matters.
Points of divergence, like a custom function that could
have just used the standard library, some unusual bit of hardware, etc,
can create problems.
They impede interoperability. They generally add something
to maintain. They add something to learn just for this project, that may not apply elsewhere.
In fact, it almost certainly won't apply elsewhere, because when you get in the habit of building
just the perfect solution to every task, you're probably going to start from scratch again next time.
When I get annoyed at this kind of thing, I often find myself saying “Just right is all wrong”, meaning that if something is perfectly suited to the application in every way, with nothing that isn't needed and everything that is, it's probably going to have issues in the real world,
where the application is less well defined.
Every tool you use has a certain amount of “Necessary Divergence”. When you add this tool,
how much custom, application specific stuff do you need to stack on top to make it useful?
Does the application find your printer automatically, or is there a config file?
Do the default settings work, or is tweaking required? If you need to change something,
is that change a single, isolated, automatable unit, like a config file dropped into a directory,
or is it stored in a database, requiring manual use of GUI tools or detailed knowledge of an API?
I believe this need for high-effort customization is both orthogonal to, and worse than, both
complexity and tight coupling. Instead of something complex that *might* be a hassle,
this high level of divergence is a way to directly express the fact that it *is* a hassle.
Software doesn't have to diverge with the norms to have weight. Anything “heavy” the software
requires of you can eventually feel like a burden, making you wish the thing never existed.
Weight can be a SaaS monthly fee. Weight can be a requirement to run on modern hardware, or to have a quality internet connection.
Weight can be long build times, heavy setup, and, at a certain point, complexity can become a weight that requires effort.
Sometimes weight is vendor lock-in. Sometimes it can be a lack of configurability or scriptability
that keeps it from fitting the application.
Sometimes, it's a negative environment consequence, like tre massive energy use of bitcoin
There are many things software can demand of us. And it had better be worth it!
Sometimes, a bit of custom work can be lighter than the existing solutions. But not that often.
And worse, if you don't bother learning the industry standard, how will you even know if your custom work is truly saving time?
Why should we praise software for being “light” if it drags our life down in other ways?
I've had about enough of heavy software. Not in terms of CPU or RAM, but in terms of hours.
I don't care what the weight is. Whether I'm wasting my time reading manuals, or waiting for it to load, it's all the same. Wasted time(Although time spent reading the manual is slightly worse, because I can't be doing something else).
It's all a problem that I don't want. I want tech to work like it does in the movies.
It should just work, every time. It should be obvious how to use it. It should be fast.
It can be as big and complex as it wants, as long as it's got unit tests and nobody
has to rewrite it every three months.
In a Marvel movie, tech is part of the story. Sometimes a key element, or even most of the
actual plot, but it never overshadows the characters.
I'm sure Fitz and Simmons spend plenty of long hours in the lab debugging just like we do,
but when they're done, and they take the whole thing into the field, *it just works*.
Unfortunately, not all modern tech has that payoff, especially DIY stuff.
Some is just an endless maintenance treadmill, wondering why the lights don't turn on in your custom home automation, or why the transparency isn't right in your riced Linux setup.
And sometimes, this kind of weight is even worse than buggy software.
90s computers crashed ALL the time. But yet, we probably spent less time on
them, and got more productivity and enjoyment than we do now.
Sometimes they didn't work, but we survived, and, except in the kind of epic crashes
that are thankfully uncommon now, maintaining our computer wasn't like a second part time job, at least for most of us.
I'm still going to be sticking to free software whenever I can. But I'm going to l
spend even less time than before customizing and tweaking and building my own experimental stuff.
And I'm going to try even harder to make things work with existing standards, rather than
go off the beaten path.
Because I want to build fantastic apps, or just not build them at all. And even if the app itself is great, in my mind, just the fact of being custom, is a downside that needs to be carefully weighed. Sometimes, it's the way to go, but only carefully.
We deserve to have lives outside of programming. If that means I'm not going to learn the details of runit or FreeBSD this year, or even that I have to pay for a few bits of software, or
even *gasp* get up to turn on a light, or do that most dreadful and shame-filled chore called “Making my own music playlist instead of building a robot to tell me what to listen to” I think that's probably worth it.