Live data from Hacker News

Do-nothing scripting: the key to gradual automation

blog.danslimmon.com

31–40 of 126 posts

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

#31

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…

Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base

It’s very different, in at least two ways:

- If your checklist is on a wiki, people may stop referring to the checklist once they’re familiar with the process. That’s bad if there are important changes. But if the process is “run this script and do what it says”, I think people are much more likely to keep doing that.

- When you start automating steps, people using the checklist pick up that automation for free. With a checklist on a wiki, any new automation means the user has to do something differently (eg maybe step 10 is “run this script” instead of “log on to the dev console and disable write access”)

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

#32
post #25

Is anyone else bothered by how they were handling ssh keys in the example? The whole point of public keys is that the private key never has to leave the box it’s generated on. Once you go sharing them you might as well just use a random passphrase.

Yes, very much so. In addition stop using RSA[0] and use ed25519 with `ssh-keygen -t ed25519`

[0]: https://blog.trailofbits.com/2019/07/08/fuck-rsa/

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

#33
post #5

I can't help looking at this and working out how to build a tool that can generate a Do Nothing script straight from your histfile, making the business of archiving the commands you just executed as easy as possible too...

Reminds me of the time I decided to try kanban to start moving forward on tasks I procrastinate on or have trouble starting.

Of course, to make sure it was efficient enough to be helpful it had to be a configurable terminal app I could quickly update and review via cli and abundant io flags/options.

It also made sense to write it in Scheme because I had been thinking I wanted to try Lisp earlier that day.

Fast-forward three weeks and I find myself hopelessly trying to refactor this strangely ugly-beautiful ascii-art themed effort tracker run by an abomination of labrynthine "functional" source and realize (maybe just finally admit to myself) it was all an excuse to avoid all that shit I'd convinced myself I was going to acheive by kanbanning in the first place.

The best part is I regret nothing!

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

#34

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

I think dual screen solution provides exactly that. Working only on a corporate laptop is very inefficient in this regard.

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

#35

This idea is great. You could even argue that these scripts actually do something: they allow storing and updating the state of a process. By having these scripts run in a shell rather than in your head, the current state is stored in a machine, not in an unreliable human brain.

also they allow you to gradually script stuff as you figure it out.

This should be read in conjunction with this other great article about how to gradually automate your process: https://queue.acm.org/detail.cfm?id=3197520

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

#38

This idea is great. You could even argue that these scripts actually do something: they allow storing and updating the state of a process. By having these scripts run in a shell rather than in your head, the current state is stored in a machine, not in an unreliable human brain.

also they allow you to gradually script stuff as you figure it out.

That looks to be a big advantage of scripts like this, they allow the gradual automation of processes.

I realized that I've written scripts that are "executable checklists", but didn't see it as a design pattern until reading this article. Typically such a script starts out as fully manual (do this, do that next, copy here, paste there..) then I replace steps as actual code, where I can, while some steps remain manual if needed.

Great use of such checklist scripts is on-boarding collaborators or new team members in a project.

Also, as grandparent comment pointed out, they reduce cognitive load by keeping the state of a process outside the head.

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

#39
I know this isn’t the point of the article but the code shown there is the archetypal case where writing classes is an anti-pattern, as argued in “Stop Writing Classes” [1]. All the classes in that code can — should! — be functions. There’s no downside, and it’s less code (and otherwise identical).

[1] https://news.ycombinator.com/item?id=3717715

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

#40
post #39

I know this isn’t the point of the article but the code shown there is the archetypal case where writing classes is an anti-pattern, as argued in “Stop Writing Classes” [1]. All the classes in that code can — should! — be functions. There’s no downside, and it’s less code (and otherwise identical). [1] https://news.ycombinator.com/item?id=3717715

maybe he was a Java programmer?

all joking aside, the reason he's doing classes seems to be an intention towards making a FooStep (and/or a BarStep) which could then maybe handle generic Foo stuff (authentication comes to mind) in the future?

Post reply on HN