This is a futile attempt to nail down an aesthetic of software I like. It won't necessarily all fit together neatly; I'm taking the sommelier approach of just saying a bunch of words and hoping that it conveys the right vibe.
One aspect I think hits on a lot of it is what I'm going to call Infinite Eternal Bus Factor. In terms of software, the Bus Factor is a simple stement of reliability: how many people need to get hit by a bus for this project to die. If a project has only 1 person who works on it, for example, it has a bus factor of 1. If any of the core Linux developers had a heart attack and died tomorrow, it'd still go on without too much interruption.
What I'm proposing as a good aesthetic choice goes a bit further. This is something more like pcc or microemacs where all of the developers can drop off the face of the Earth, then years later someone can come by, dust it off, and get it back into usable shape. Pick some n for the number of years (10 or 20? Something round.)
There's a natural rebuttal in that there are no concrete prescriptions here, but that's why it's an aesthetic rather than a methodology or anything more concrete than that: you have to know it when you see it. Worse: strictly speaking you don't know it until you see it decades down the line.
While the distinction between a high bus factor and an infinite one might seem small, there's actually a huge gulf between them. Most immediately: the program must require no living knowledge that can't be rebuilt. This is huge, and it immediately disqualifies every piece of software a normal person would use. Nothing backed by a web browser would make it. I don't think any office suite would. Some email clients might.
Tips for writing software that fits this: use older languages. Use older tools. Use libraries which do less. Prefer smaller dependency chains, ideally the number of libraries between your app and libc/syscalls/X|Wayland should be countable on your fingers. Avoid using obscure features which alternate implementations of your language might not pick up on (related: test your software on alternate implementations. For a real world example I ran into: did you know that const char *str = {"abcdefg"}; is valid C?)
Make sure your software is readable. It may not be a terrible idea to look up a decent coding standard like OpenBSD's. me is very much guilty of problems here, but there's only so much I can expect out of a nearly 40 year old codebase meant to support dos and unix side by side, as well as the mess of incompatibilities that was unix in the 80's and 90's. I'm working on that bit.
In addition to the IEBF, since that doesn't say much about the runtime, I think it's worth considering scavenger-proofing your software. This ties in with some of the practical side of IEBF-friendliness but it speaks more to the kind of hardware you should run on. Consider: we are currently (in 2022) in the middle of what one might call an apocalypse. Ignoring the past 2 years of plague essentially nothing has been done which will realistically halt or even slow down global warming. The first countries are disappearing due to rising sea levels now and just about all of the planet's industrial capacity, just like in every other period in history, is in low lying areas. What I'm saying here is that TSMC and Foxcon aren't going to be churning out fancy, fast chips forever. In the not too distant future (which you should be designing for,) you're going to take pretty much whatever you can get in terms of computing devices, so old hardware, partially broken hardware which has had some of its RAM knocked out or which is kept at low clock speeds due to thermal throttling, etc. Your work should be useful on what someone can dumpster dive now.
What does this look like in practice? Well, old software is a given. I've shouted out microemacs, which is great if your pinkies can handle it. I've been having a good time with acme. One particularly interesting example, though, is uxn, a tiny forth-ey "retrocomputer" which runs on everything from smartphones to browsers to Raspberry Pis to a Nintendo DS. That one. From 2004. It provides an incredibly fun recreational programming environment while letting you construct real software which could, with a tiny bit of care and attention, easily run on machines that are 25+ years old.