For example. The "saves 5 seconds task that I do once a month" from the blog post. Hopefully the author did not spend more than 5 minutes writing said script and maintaining it, or they're losing time in the long run.
1. even if it costs more time, it could also save more annoyance which could be a benefit
2. by publishing the scripts, anyone else who comes across them can use them and save time without the initial cost. similarly, making and sharing these can encourage others to share their own scripts, some of which the author could save time with
The annoyance of all these factors for outweighs the benefits, in my experience. It's just that the scripts feel good at first and the annoyance doesn't come until later and eventually you abandon them.
Sounds like something you could automate with a script :)
If something is time sensitive it is worth spending a disproportionate amount of time to speed things up at some later time. For example if you’re debugging something live, in a live presentation, working on something with a tight deadline etc.
Also you don’t necessarily know how often you’ll do something anyways.
The xkcd doesn't seem to be pushing an agenda, just providing a lookup table. Time spent vs time saved is factual.
To take a concrete example, if I spend 30 minutes on a task every six months, over 5 years that’s 5 hours of “work” hours. So the implication is that it’s not worth automating if it takes more than 5 hours to automate.
But if those are 5 hours of application downtime, it’s pretty clearly worth it even if I have to spend way more than 5 hours to reduce downtime.
>YOU DON'T UNDERSTAND. I NEED TO BE CONSTANTLY OPTIMIZING MY UPTIME. THE SCIENCE DEMANDS IT. TIMEMAXXING. I CAN'T FREELY EXPLORE OR BRAINSTORM, IT'S NOT XKCD 1205 COMPLIANT. I MUST EVALUATE EVERY PROPOSED ACTIVITY AGAINST THE TIME-OPTIMIZATION-PIVOT-TABLE.If you have to do that, the script needs improvement. Always add a `--help` which explains what it does and what arguments it takes.
----
https://github.com/p-ranav/argparse is a single-file argparse for Modern C++, which means it's typically straightforward, if baffling in places and a bit annoying to step through in the debugger.
The nice thing about the argparse ports is that provided they take their job seriously, your programs will all end up with a vaguely consistent command line UX in terms of longopt syntax, and, importantly, a --help page.
My favorite recent one was Handmade Seattle, but that one's kaput as of this year, and it seems everything else along similar lines is overseas and/or invite-only.
Of course, I _do_ have some custom shell scripts and aliases, but these are only for things I will ever do locally.
What's always interesting to me is how many of these I'll see and initially think, "I don't really need that." Because I'm well aware of the effect (which I'm sure has a name - I suppose it's similar to induced demand) of "make $uncommon_task much cheaper" -> "$uncommon_task becomes the basis of an entirely new workflow/skill". So I'm going to try out most of them and see what sticks!
Also: really love the style of the post. It's very clear but also includes super valuable information about how often the author actually uses each script, to get a sense ahead of time for which ones are more likely to trigger the effect described above.
A final aside about my own workflows which betrays my origins... for some of these operations and for others i occasionally need, I'll just open a browser dev tools window and use JS to do it, for example lowercasing a string :)