4 ms·

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 u

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.

te_cima 1y ago
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.
- akersten 1y ago
  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/ 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.
  - kelvinjps10 1y ago
    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.
  - skydhash 1y ago
    Sometimes, you explore to have ideas. By fixing a few problems like these, you learn about technologies that can help you in another situation.
  - duskdozer 1y ago
    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
    - chipsrafferty 1y ago
      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.
      - yellowapple 1y ago
        > Every time I get a new system I would have to set everything up again Sounds like something you could automate with a script :)
  - janalsncm 1y ago
    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.
    - normie3000 1y ago
      > 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.
      - janalsncm 1y ago
        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.
        yellowapple 1y ago
        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.
  - latexr 1y ago
    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.
    - dbalatero 1y ago
      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.
  - r4tionalistmind 1y ago
    >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.
- chipsrafferty 1y ago
  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.
karczex 1y ago
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.
taejavu 1y ago
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.
latexr 1y ago
> 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.
- tom_ 1y ago
  If you write these sorts of things in Python, argparse is worth investigating: https://docs.python.org/3/library/argparse.html 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!
  - latexr 1y ago
    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/ruby/optparse ² https://github.com/apple/swift-argument-parser https://github.com/apple/swift-argument-parser
    - yellowapple 1y ago
      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 https://github.com/YellowApple/bales
    - tom_ 1y ago
      Regarding other ports, I've also been pretty happy with https://github.com/nodeca/argparse 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 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.

te_cima 1y ago

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.

akersten 1y ago
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/ 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.
- kelvinjps10 1y ago
  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.
- skydhash 1y ago
  Sometimes, you explore to have ideas. By fixing a few problems like these, you learn about technologies that can help you in another situation.
- duskdozer 1y ago
  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
  - chipsrafferty 1y ago
    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.
    - yellowapple 1y ago
      > Every time I get a new system I would have to set everything up again Sounds like something you could automate with a script :)
- janalsncm 1y ago
  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.
  - normie3000 1y ago
    > 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.
    - janalsncm 1y ago
      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.
      - yellowapple 1y ago
        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.
- latexr 1y ago
  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.
  - dbalatero 1y ago
    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.
- r4tionalistmind 1y ago
  >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.
chipsrafferty 1y ago
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.

karczex 1y ago

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.

taejavu 1y ago

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.

latexr 1y ago

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

tom_ 1y ago
If you write these sorts of things in Python, argparse is worth investigating: https://docs.python.org/3/library/argparse.html 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!
- latexr 1y ago
  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/ruby/optparse ² https://github.com/apple/swift-argument-parser https://github.com/apple/swift-argument-parser
  - yellowapple 1y ago
    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 https://github.com/YellowApple/bales
  - tom_ 1y ago
    Regarding other ports, I've also been pretty happy with https://github.com/nodeca/argparse 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 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.