Hacker News Reader

Comment by chipsrafferty | Hacker News Reader

I'd love to see a cost benefit analysis of the author's approach vs yours, which includes the time it took the author to create the scripts, remember/learn to use them/reference them when forgetting syntax, plus time spent migrating whenever changing systems.

View on HN

Not all time is created equal. I’ll happily invest more time than I’ll ever get back in refining a script or vim config or whatever, so that later, when I’m busy and don’t have time to muck around, I can stay in the flow and not be annoyed by distractions.

Sometimes it's rather matter of sanity than time management. I once created systemd service which goes to company web page and downloads some files which I sometimes need. This script was pretty hacky, and writing it took me a lot of time - probably more than clicking manually on this page in the long run. But clicking it so annoying, that I feel it was totally worth.

why is this interesting to you? the whole point of doing all of this is to be more efficient in the long run. of course there is an initial setup cost and learning curve after which you will hopefully feel quite efficient with your development environment. you are making it sound like it is not worth the effort because you have to potentially spend time learning "it"? i do not believe that it takes long to "learning" it, but of course it can differ a lot from person to person. your remarks seem like non-issues to me.

It's interesting because there's a significant chance one wastes more time tinkering around with custom scripts than saving in the long run. See https://xkcd.com/1205/

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.

Maybe, but

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

In my experience, it's not "maybe" but "almost certainly" which is why I stopped doing this. Every time I get a new system I would have to set everything up again, it's not cross platform, doesn't work when using someone else's computer, suddenly breaks for some reason or another, or you forget it exists...

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.

> Every time I get a new system I would have to set everything up again

Sounds like something you could automate with a script :)

Sometimes, you explore to have ideas. By fixing a few problems like these, you learn about technologies that can help you in another situation.

Not all time is created equally though, so I disagree with that xkcd.

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.

> I disagree with that xkcd

The xkcd doesn't seem to be pushing an agenda, just providing a lookup table. Time spent vs time saved is factual.

The title of the comic is “ Is It Worth the Time?”.

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.

Time saved also ain't the only factor here. I'll often automate something not because it actually saves a lot of time, but rather because it codifies an error-prone process and having it scripted out reduces the risk of human error by enough of a degree to be worth spending more time on it than I'd save.

I find that now with AI, you can make scripts very quickly, reducing the time to write them by a lot. There is still some time needed for prompting and testing but still.

One thing which is often ignored in these discussions is the experience you gain. The time you “wasted” on your previous scripts by taking longer to write them compounds in time saved in the future because you can now write more complex tasks faster.

The problem is, to really internalize that benefit, one would need to have an open mind to trying things out, and many folks seem to resist that. Oh well, more brain connections for me I suppose.

    >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.

Because some of them OP said they use a few times a year. This means they'll probably use it like 150 times in their life. If it saves a minute each time, but it takes 5 hours to create it and 5 hours to maintain it over the years, then it's not really a win.

> reference them when forgetting syntax

If you have to do that, the script needs improvement. Always add a `--help` which explains what it does and what arguments it takes.

If you write these sorts of things in Python, argparse is worth investigating: https://docs.python.org/3/library/argparse.html - it's pretty easy to use, makes it easy to separate the command line handling from the rest of the code, and, importantly, will generate a --help page for you. And if you want something it can't do, you can still always write the code yourself!

I don’t like Python in general, but even so I’ll say that argparse is indeed very nice. When I was writing ruby, I always felt that OptionParser¹ wasn’t as good. Swift has Argument Parser², officially from Apple, which is quite featureful. For shell, I have a a couple of bespoke patterns I have been reusing in every script for many years.

¹ https://github.com/ruby/optparse

² https://github.com/apple/swift-argument-parser

Regarding other ports, I've also been pretty happy with https://github.com/nodeca/argparse, which works nicely from Typescript. Looks like it hasn't been updated for a while, but it's not like there's a great deal wrong with it.

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.

Many years ago I wrote a library I called “Ruby on Bales”¹ specifically due to my frustrations with the state of command-line argument parsing for Ruby scripts. I haven't touched it in a long while; maybe I should revisit it.

----

¹ https://github.com/YellowApple/bales

Reply on news.ycombinator.com