CustomizationSensibleLimits

By admin
Recently, for reasons beyond the scope of this entry, I’ve been mostly handling my email in

GNU Emacs
PRODUCT

, with

MH-E. GNU Emacs
ORG

is famously flexible and customizable, mostly through the somewhat challenging method of ‘merely’ writing the relevant (Emacs) Lisp code to do what you want. I’m capable of writing

Emacs
PRODUCT

Lisp, so armed with a hammer and using a new mail client, I have been finding plenty of things to use that hammer on (sometimes with hackery and Emacs crimes). At this point, I’ve accumulated something like

1500
CARDINAL

lines worth of customization (although that includes a lot of comments), and I can think of more things that I might do.

(Some of this customization is because MH-E doesn’t quite do what I want it to do, sometimes it’s because I want a more convenient way to do what it already can do inconveniently, and sometimes it’s because I’m trying to recreate features I’m used to in exmh.)


Several years ago
DATE

I read

Tobias Bernard’s
PERSON

Doing Things That Scale. To summarize the article badly,

Tobias Bernard
PERSON

talked about how they had moved away from customizing things (and then having to maintain the customizations) in favour of doing generally useful changes to upstreams. This argument gave me tangled feelings that I’ve yet to sort out enough to write an entry here about, but part of it is certainly on point. Every customization I make to my Emacs and

MH-E
PRODUCT

setup is effort to write, effort to remember, and effort to maintain. Do I actually need an ultra-hyper-customized

MH-E
PRODUCT

environment? Am I going to even use all of these hacks I’ve done? Both clothes and mail clients can be comfortable and useful without being form fitting.

Of course, this is a personal version of something that I run into all of the time professionally, as a system administrator. There’s a lot of custom scripts, custom

Prometheus
ORG

metrics exporters, custom web things, custom mail system features, and so on that we could write and put into production, but all of them have both a cost and a benefit, and sometimes the costs are not worth the benefits. Just because we can do something doesn’t mean that we should. At the same time, sometimes we should, even if the customization is large and thus the costs are significant.

(For example, we have a bespoke custom

ZFS
ORG

spares system, which was a chunk of work to write and tune, but on the other hand has been rock solid and lets us basically not worry about disk problems. And our very custom simple mailing list system is quite appreciated by our users, although the Exim configuration involved is surprisingly complex.)

I don’t have any particular answers, either for my sysadmin work or for my

GNU Emacs
PRODUCT

hacking. But I do want to think about the question at least a bit, even (especially) for my own

GNU Emacs
PRODUCT

coding. Just because something is an interesting

Emacs
PRODUCT

Lisp problem doesn’t mean that I should solve it, especially if I’m currently immersed in solving

Emacs
PRODUCT

Lisp problems. And just because I can tweak and customize something doesn’t mean that I should.

(

Solving Emacs Lisp
WORK_OF_ART

problems is a little bit addicting for me, much like any programming. Sometimes I have to pull myself away from the urge to do a bit more and then a bit more and so on. Hopefully this urge will pass.)