Pasting all the commands in a doc that you keep around seems to give 90% of the benefit of automating it for 1-4 times per year tasks.

It's not typing the commands that takes time, it's remembering what commands to type.

Do hard things more often. https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

Absolutely, I try to "automate" or at least have scripted almost everything I do.

I do this almost always for reproducibility and documentation purposes first.

It may not be worth the time to automate those, but I always take the time to document them, usually in Obsidian, where I can easily find them later.

I’m a big fan of writing things down for future reference. Keeping a journal with things like exactly which commands I used, or transferring that knowledge to something like a README or a wiki page for others to see, is a low effort but sometimes high reward habit. Even for something done only rarely, saving a lot of time next time can justify the documentation effort.

Similarly, if the automation effort is literally only copying those commands verbatim into a shell script or similar, that’s often time well spent. The trap, as the XKCD helpfully demonstrates, is when you then start spending significantly longer on making that script more “flexible”. Turning hard coded values into parameters. Looking context up from the environment. On multiple development platforms. In staging, UAT and production deployments too. With detailed help text to explain it all and say what the defaults for everything are if you don’t specify them explicitly. And then it turns out that you only actually run that script once every six months anyway and never use 95% of that extra flexibility anyway…