11 comments

[ 2.3 ms ] story [ 44.4 ms ] thread
Agree with the author. I have many simple automation scripts that are not written to the standard of my professional pride because it helps me stay in the flow.

Often, people say that you should only automate things if it saves you time overall: spend 5 minutes writing a script only if it saves you 6 minutes. However, not all minutes are equal. 5 minutes when you are close to a deadline is far more valuable than 5 minutes when you are "idling".

For this reason, I always appreciate it if tools are written with automatability in mind, even if they may not save a lot of time when automated. If I have to use PyAutoGui for every automation I write, I think it will be a lot more brittle than I like. If it uses two-factor authentication, it makes the automation even less "flow-breaking".

> Often, people say that you should only automate things if it saves you time overall

I was trained years ago by people who said "if you have to repeat a task, automate it; any time spent repeating a script is waste but time spent automating is learning to automate better _and_ not repeating yourself."

Also the automation is documentation for next time you have to do it. Even if it doesn't work!
[flagged]
Whoa. That feels like a while lot of words to say nothing.

Is this a ChatGPT/similar response or what?

This is an already solved problem:

  - package everything, *especially configuration*;
  - executables in /opt/someprefix/bin, no extensions;
  - daemons (services), executables with elevated privileges go into /opt/someprefix/sbin/;
  - read only data which the application needs to run goes int /opt/someprefix/share/application/;
  - logs should be streamed to syslogd, for example via the logger utility, so that centrally configured OS logging is honored and the application doesn't vomit out log files arbitrarily or at arbitrary, private locations;
  - application data should go to /var/opt/someprefix/application/;
  - configuration in /etc/opt/someprefix[/application] (if more than one configration file, otherwise /etc/opt/someprefix/);
  - configuration files should have a .conf or .cf postfix, and should be plain ASCII text files, but not YAML, JSON, or XML.
These are industry norms, formally written as specifications:

https://illumos.org/man/7/intro

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#et...

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#op...

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#va...

...and most important of all: deliver quality manual pages in /opt/someprefix/share/man for your tools, with lots of examples! No wikis, markups, HTML web pages, none of that junk: straight, honest to goodness manual pages available at one's fingertips on the command line.

> automating small tasks in order to maintain concentration, not to save time

Frankly, I don't see the difference. They're both examples of what Larry Wall (may his mustache remain ample and bushy!) called "laziness," and I favor laziness.

https://thethreevirtues.com

I mostly use Makefiles to remember what I've written. It makes it quite easy to see what actions I found useful when working on some project months or years ago. Even if it's just calling out to scripts, it's nice to have in a central place.
> I’ve heard many people say you should automate repetitive tasks; I’ve never heard anyone discuss the problem of remembering what you’ve automated and how to invoke it.

The trick is to automate that :)

From a productivity point of view, I agree for the fact to limit the number of tool used. But personally, I will advice the reverse, to try different ones, in order to get a larger palette, and learn more. Often in software, tools shape the mindset.

Someone using Python to automate versus someone that is using awk or even someone using some old point-and-click RPA have very different approaches on how to solve an automation problem.