The first thing I wrote when I started this essay was, "Written 2026-09-01." Then I wrote "Idea long before that". Then I opened my post ideas file and searched for "metadata", and found the line where I had written down the title for this essay, four years ago. Then I wrote "Idea and title 2022-07-30".

Does this sound tedious? It is tedious. But, it's worth it.

I have written before about how much I like dating. (No, no, not that kind of dating. ISO_8601 dating!) But my obsession with timestamps is just part of a broader belief in the long-term value of metadata.

Why save metadata? Briefly: because it's way easier to record data when it's fresh, than to have to piece it together later.

Additionally, I think that:

1. We wildly overestimate our chance of remembering things.
2. We often have no idea what will prove to be important.

We think, oh, that doesn't matter. Or, oh, I'll never forget that. But it does, and I will, and I'll only realize that it does after I have.

More likely, someone else will realize it does, long after I'm gone. And they'll be like me: wasting a non-profit's money and getting a headache trying to trace the provenance of obscure foreign-language manuscripts that were published under different titles in different languages.

What does this mean in practice? Here are some examples:

I write songs. When I write a song, I make sure to:

1. record a memo of it
2. write down the lyrics
3. put the chords in the lyrics
4. fill out a template with all kinds of boring stuff about it: the key, capo position, accompaniment, date started, date worked, date finished, tempo.

At the time the song is fresh, it all seems a bit absurd. Am I really going to forget what instrument I play on a song that I wrote? A song that took me, probably, a day to six months to finish? Am I going to forget what key it's in? Forget what order the three chords go in?

Yes, yes I am. And years later, the drummer is going to forget he played drums, and try to play cello on it, and it will sound bad.

Some songwriters I know don't put the chords in their songs, or notate the key. They are the creative types that write in a cute little notebook, and haven't written custom software for managing their song catalogue. Then, years later, they try to play them, and discover that they have forgotten which order the three chords go in.

(Fun fact of interest of to almost nobody, because the Venn diagrams of "songwriters" and "nerd" have so little overlap: Regex can make adding chord notation to lyrics way faster.)

Also, lyrics will drift. Usually this is good. Unmemorable parts get dropped, just like with folk songs. But sometimes you want to go back to the first version, in case something good got left by the wayside.

Code comments are another obvious form of metadata:

I write a lot of infrequently used shell scripts. Some of them are meant to be run from a particular place, or as a step in a pipeline, or are full of known footguns that I haven't bothered to fix. It saves a lot of time to add a comment at the top with usage instructions, while I still remember how to run the script. Better yet, echo the usage instructions, and exit if the config is wrong.

I also think of logging as a form of metadata. As soon as something breaks, the first thing I do is add logging. So I've started by adding logging right at the beginning, so all I need to do when the software breaks is turn on the logging.

If you have gone to the dark side, I highly recommend that you record:

• what model you used
• if running locally: quantization, inference engine, and parameters
• the prompt

The thing about vibecoding is that you don't understand it, so you don't remember it. This paper trail allows me to remember where I was on a project, if it gets shelved and then I try to come back to it.

If you're a writer, have a good schema for tracking different versions of things. Fancy people use git; I use numbers at the end of the filename. Title final-final-FINAL.doc does not count as "a good schema for tracking different versions of things".

Any time I write an email in a text editor, and then paste it into my email client before sending, and then tweak it in the email editor, I add a note to the text file NOT UP TO DATE. (Sometimes, I put CANONICAL VERSION in whatever is the up-to-date version of a document that lives multiple places, in different forms. This is, of course, fragile, but it's often better than nothing).

When I scan papers, I pencil on them that they have been scanned (or, typed in), and the date.

Another reason to save metadata: to protect against lawsuits. Often, I write something, or write a song, and then notice a similarity to some other work. If I saved a good record of my process, I can cross-reference: had I read that article, or heard that song, before I started mine?

Obviously, if you are into plagiarism, then you probably shouldn't save metadata, since it will make it easier for them to catch you!

When I buy a piece of clothing, I write down the date I bought it, the size, and the make in “Product Info.txt”. Isn’t that absurd? All that information is right there on the tag! That’s true: but tags fade into unreadability years before the clothing wears out and needs to be replaced. And, if I lose the clothing, I can’t check the tag to figure out what needs to be replaced.

Another kind of metadata is indexing metadata. It's not data about what, it's data about where: lightweight, easy-to-find data that points to heavy buried (meta)data somewhere else. Things like unreasonably long filenames, and notes about where the notes are.

What are the reasons not to save metadata?

• It's slow
• It takes up space
• It's tedious
• It's revealing

These are legitimate reasons, but in most cases, I think they are outweighed by the benefits.

Metadata adds the fourth dimension to your projects: their trajectory through time. It's much easier to steer something into the future if you know the path it took on its way to the present.