Iterative Tinkering depends on API stability

Sacha Chua writes how she tinkers incrementally, finding time between tasks, asking “What's the smallest step I can take? What can I fit in 15-30 minutes?” — Choosing what to hack on. This approach improves the work environment step by step to become better than any other. In a similar way, I now ended up using exwm, and while not perfect, it just works better for me than all other systems.

A message written to emacs devel, because Emacs is one of the shining examples where this usually works, but it recently saw some breakage.

PDF (drucken)

This approach improves the work environment step by step to become better than any other. In a similar way, I now ended up using exwm, and while not perfect, it just works better for me than all other systems.

But since this depends on doing small steps and moving forwards in little steps, there’s no time for large-scale maintenance. You define what’s the right step, and then you take it.

If something breaks, that takes up at least a full improvement slot. Often just searching for a solution takes longer than you have.

So this approach — which can lead to the best personal work environment possible — depends critically on API stability. Even a deprecation that affects multiple of your modifications can put a stop on tinkering for a long time, because fixing something that broke due to changes from someone else is a very different kind of working than letting your curiosity lead to even out a rough edge in your workflows.

Someone would surely come in and quote xkcd 1172. I consider that a harmful strip — it has a point, but it got weaponized to brush away concerns about stability and muddies up the understanding that those with the most complex or most advanced setup are the ones most likely hit by API breakages.

If you see 1172, remember that Lilypond had almost ended up ditching Guile because of breakage that hit them with the 2.0 release. The one Guile-using tool that is absolutely dominant in its domain (the most beautiful music scribe) had almost stopped using Guile.

For Emacs, the impact is even bigger, because far more people tinker to optimize their setup.

And recently I’ve seen more breakage in Emacs.

For example my address completion in mu4e broke a week ago. I don’t have time or energy to fix it. And mu4e started to send emails to myself if I answer my own message in a thread with someone else, because the R shortcut no longer sends wide replies (W shortcut). And there’s a risk that it will stay broken: storing each address I send emails to in mu4e automatically has been broken for years. It took me months before I got to fix my org-mode setup when it suddenly started indenting lines while typing. That actually affected me live while giving parts of a lecture interactively.

So I want to plead to remember the risk of volatile software¹, volatile infrastructure², and soft trauma³, when taking decisions about backwards compatibility.

Breaking backwards compatibility has much wider-ranging implications than it seems while working on code, and it hits the most most advanced specialist tooling and the most enthusiastic tinkerers the worst.

And while avoiding to break backwards compatibility is not always possible, there are often non-obvious ways to preserve compatibility even when large changes are needed to move forward.