Dan Slimmon writes about operations, incident troubleshooting, queueing, and practical automation for software engineers.
Commenters link it often for the do-nothing scripting idea and the queue utilization post; one asks why such scripts use a class with a single run method.
I'm basically of the same opinion as you, but recently read this article[0] on "do nothing" scripts and really like it. The idea is to write at your process _as a script_ that will at first just print what to do. Then you can use computer magic to improve things over time and automate steps in the middle.
I generally agree that there are a lot of processes that are like "use your brain and think at this step", which is hard to automate, really. Open-ended workflow tools don't really exist for this kind of thing.
(Clarifying example: what script do you write to "diagnose a response time spike"? You can definitely write up usual suspects but at one point you don't have a script that gets you from the beginning to end )
[0]: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/
I have a very similar setup but with HLedger[1]. A "do-nothing"[2] script helps me download statements by opening bank websites, waits for manual import and finally checks balances. That makes it a lot less repetitive and error prone. Or at least, I catch the errors faster.
I've found HLedger and Shake to be fast enough to process almost a decade of finances. Dmitry Astapov has an extremely well produced tutorial workflow[3].
How have you managed the PDF parsing? Mine has become a bit of a mess dealing with slight variations in formatting as they change over time. I've been considering using LLMs but have been nervous about quality.
[1]: https://hledger.org [2]: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation [3]: https://github.com/adept/full-fledged-hledger
The Do Nothing Scripting [1] is an approach that I feel recognizes the difficulty of automation by starting out with a script that just tells you what to do like a checklist. Once you've used it to fully document all the exceptions, etc. you can then start building the automation.
An approach like this seems to give more weight to the fact that just figuring out a way to document exactly what needs to be done is often the hardest part and if you get that right before you start writing automation code, it might make make the automation much more efficient.
[1] https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/
Start writing down the bash commands that you use to build and deploy your app locally.
For manual steps just write down a description to make a "do-nothing script" [1] to transition with gradual automation .
Then you can turn those into the rough draft of your CI/CD a pipeline.
If you use a common system there might already be adapters for your CI/CD platform of choice to make it even easier.
GitHub Actions is a good simple system to start with if your code is on GitHub.
[1]: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/
There is also a mathematical relationship in queuing theory between utilization and average queue length, which all programmers should be told: https://blog.danslimmon.com/2016/08/26/the-most-important-thing-to-understand-about-queues/
As you run close to 100% utilization, you also run close to infinity waiting times. You don't want that. It might be acceptable for your internal projects (the actual waiting time won't be infinity, and you'll cancel them if it gets too close to infinity) but it's certainly not acceptable for customers.
This sounds like what you want
https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/
Found via https://dotat.at/:/?q=automati
I also searched for “run book” but that didn’t turn up anything likely. Although a runbook is often a good starting point for automation, this do-nothing script idea probably makes the path from documentation to automation more direct...