As someone who is separately both a programmer and an archeologist, I love the concept and the books. The real skills aren't always as far apart as you'd think either. I once spent a week deconstructing hardware to figure out what assembly language a project was written in. The assembly was only documented in a TRM in a dusty filing cabinet written before I was born. Once I could read the assembly I could read the source code and work my way up the stack to start answering the actual questions I had.

The nice thing with software is that everyone gets to be an archaeologist in short order; ~6 months is more than enough...

  - Howdy! there's a bug!
  - Okie, lookie!
  *dig dig dig, stares at line 47*
  - Oh my, this horsemanure could not have possibly worked, ever! What kind of damaged wetware wrote this?!
  $ git blame
  - Oh.

I like to say that git blame is a great tool for working out that the problematic code you’re looking at was in fact written by yourself.

For sure, I imagine "software archaeology" will become a field of its own in the future. It reminds me of GitHub's Arctic Code Vault project, a snapshot of all public repositories as of 2020-02-02, meant to last for at least a thousand years.

https://github.blog/2022-09-20-if-you-dont-make-it-beautiful...

I wonder what future humans will make of it, digging through such a massive amount of good, bad, and terrible code. Much of it probably won't run without serious effort.

I can't even run a node.js project that was written two years ago.

That's probably for the best