At Netflix, our philosophy was to try and remove process at every turn. If something bad happened, we'd look at if there was a process in place, and if so where we could automate or remove that process for better outcomes.
When change requests were not accurate, we removed change requests by automating auditing of the infrastructure, so people could see exactly what state it was actually in, instead of relying on change requests.
When the process for paging someone broke down, we built automation for paging people.
There were many other examples. But always we would look for ways to eliminate process, and for ways to automate around failures instead of introducing new processes.
I've spent my time at smaller less advanced orgs. The pushback against automation, against software has been pretty high.
Skepticism of software is high; people seem to only trust things they can type into the terminal & crank out themselves. They see automated systems as too fancy, too dangerous, as unknowable. Companies and people don't take the time or opportunity to learn, understand and grow: they are committed only to the work ahead of them rather than a broader project of improving themselves & the org broadly.
It's all so backwards & sad. Seeing such persistent anti-commitment to getting good. Regularly taking the most reductionist take on what simple is, even though it so often involves complex tribal/oral knowledge with many unstated embedded choices baked in in how the org handles things.
It's a hard sell, because the base fact is that there is kind of a low cowardice pushing against creating code. Nothing is as well defined, well shareable, as explicit as code. The opportunity to learn from code is as infinite as you are willing to chase it. But people don't want to have to engage in systems or computers. They prefer informal knowledge & having regurgitated oral knowledge passed down, they dont have the fire to investigate & watch for themselves.
I hope we can keep finding ways to make automated systems better explain themselves, better show their work. Automation is just so amazing, but dealing with the fear insecurity & "I have no time for this" factor has been a miserable ever-lowering factor at most orgs I've seen. I wish geeks & orgs could believe more in trying, weren't so predisposed against figuring out good ways to pave the cowpaths.
To play devil's advocate, I frequently see people throw software and automation at problems that could've been solved with a system/design change. "We make 20 of these widgets a day, they take too long to make, let's automate it!" Unfortunately the first questions aren't always "why do we make these widgets?" or "do we have to?"
Lots of out of touch leadership types automate away system design flaws IME. Rather than automating for speed or consistency.
Sure, no code is great when it works. Usually though I think there is a real calling for forward motion, for getting better, not unwinding & disassembling.
Reagrdless of whether we agree here, the question stands of what we do when action is required.
You just go from a process where someone has to remember something to a process where a computer checks a condition thousands of times a day or whatever.
Sure, but that's my point, it boils down to good processes being better than bad processes.
I guess part of what is being talked about here is that people sometimes have trouble reasoning about automation vs reasoning about some human mediated activity.
When change requests were not accurate, we removed change requests by automating auditing of the infrastructure, so people could see exactly what state it was actually in, instead of relying on change requests.
When the process for paging someone broke down, we built automation for paging people.
There were many other examples. But always we would look for ways to eliminate process, and for ways to automate around failures instead of introducing new processes.