Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do-nothing scripting: the key to gradual automation

blog.danslimmon.com

Post reply on HN
Print view View original

21–30 of 126 posts

Re: Do-nothing scripting: the key to gradual automation

#21

Post by TuringTest »

kostarelo wrote: post #17

It seems to me that all you want is to document a manual process. Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base .e.g in Confluence or as product requirements. I can see the usage in an isolated team of a few people that will write these scripts for their own benefit. I am opposed in general with having scarce information around. Better have everyt…

There is one advantage of this script over an equivalent document: it provides the instructions in the same context that it's being used (the command shell).

Unless we have script shells that can universally launch a web document side-by-side from the shell prompt where it needs to be used, having it being displayed from the shell itself step by step will reduce the mental load required to follow the instructions. Also, the benefit of having an already semi-automated process in order to build a script in the future is not negligible.

Re: Do-nothing scripting: the key to gradual automation

#26

Post by lucideer »

kostarelo wrote: post #17

It seems to me that all you want is to document a manual process. Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base .e.g in Confluence or as product requirements. I can see the usage in an isolated team of a few people that will write these scripts for their own benefit. I am opposed in general with having scarce information around. Better have everyt…

In addition to the sibling commenters point about providing instructions in context, this approach has another much bigger advantage (mentioned in the article): it informs you of where you are in the process so you don't miss steps.

Keeping track of which step you are on while following a long doc is no easy task when some steps needs to be left unattended (and produce scrolling terminal output making viewing the last-run command harder).

Re: Do-nothing scripting: the key to gradual automation

#27

Post by dusted »

We use this at my place, though in bash, and we call it executable documentation. Stuff like:

NAME="$1"

# Create directory for the code

mkdir "$NAME"

# Checkout the source

cd $NAME && git something

# and so on

Sometimes with an echo "You need to read and understand this before just using it"; exit 1 thrown in somewhere for good measure.

These files will have no logic, and make very little use of variables. They will also have a .txt filename to ensure that people understand, that first of all, this is a set of instructions for how to do something, which just so happens to be a valid bash script.

Re: Do-nothing scripting: the key to gradual automation

#28

Post by praptak »

heinrichhartman wrote: post #4

Very nice idea, Dan! This reminds me of the power of checklists that has been discussed here a few times: Simple but highly effective. It allows for a pretty natural transition: - (Markdown) Manual - Do-nothing-script (printing out the manual in steps) - Partial automation - Full automation

The reference article for the power of checklists: https://www.newyorker.com/magazine/2007/12/10/the-checklist

Another article, with HN discussion: https://news.ycombinator.com/item?id=20293246

Re: Do-nothing scripting: the key to gradual automation

#29

Post by some_furry »

kostarelo wrote: post #17

It seems to me that all you want is to document a manual process. Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base .e.g in Confluence or as product requirements. I can see the usage in an isolated team of a few people that will write these scripts for their own benefit. I am opposed in general with having scarce information around. Better have everyt…

Furthermore, some tasks are nonlinear in complexity. Documenting those properly would quickly lead to a "choose your own adventure" type scenario.

Most documentation software (i.e. Wikis) do a poor job of encapsulating this. The "do-nothing" scripts might be easier to maintain, but it forces you to use plaintext.

I recently started an open source project that might be more helpful for teams (if for no other reason than it uses Markdown): https://faq.dhol.es/@Soatok/public-beta/what-is-faq-off

Post reply on HN