I'm so glad to see that they framed this in terms of a bug in a tool designed to prevent human error, rather than simply blaming it on human error.
Wouldn't human error reflect extremely poorly on the company though? I mean, for human error to be the root cause of this mega-outage, that would imply that the company's infrastructure and operational and security practices were so ineffective that a single person screwing up could inadvertently bring the whole company down.
A freak accident that requires all stars to be aligned to even be possible, on the other hand, does not cause a lot of concerns.
For a modern example, look for information on Symantec's "A tough day as leaders" in which they try to blame an incident that's clearly a result of at least incompetence by senior management on a single person who they've just fired. This is part of the sequence of events that leads to Symantec no longer being a trusted root CA. You won't find that actual post by Symantec because (of course) once they realised it wasn't doing what they wanted they deleted it, but you can find copies and references to it.
For much older examples, look at the early history of the railway in most of the world. Train crashes, blame the (often dead in the crash and thus unable to defend themselves) train driver, hint that they may have been drunk and were certainly incompetent. Owners carry on profiting from unsafe railway and needn't spend any money making it safer.
Truth be told, Boeing's response to the 737MAX crashes was to blame people working for other organizations, thus the blame would not fall within neither Boeing engineers/technicians nor the Boeing organization. That's a total and complete cop out.
Pinning the blame on a company employee at least implies that the company itself has some responsibility.
In other words, not human error but human error.
- Me, 2021
https://learntla.com/introduction/
I discovered it here on HN just recently, in a comment on a new tool in the same problem space.
That said, even clean, idiomatic Python isn't as terse as sh. It also isn't as terse as perl. Many would argue that's a good thing. The optimum point for readability isn't found at either of the extremes. Not entirely unlike how the most readable way of writing English is neither shorthand nor blackletter.