One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
grayhatter|14 hours ago
I would probably say a shell is "the correct tool for the job" but other than the appeal to authority, or appeal to tradition. There's not a great argument for a shell script over a language you're already comfortable with.
There are hundreds of examples that are easier or faster in python than shell.
Engineers are bad at making tooling, we're even worse making ephemeral tooling we're willing to throw away. Contrasted with other makers, you have machinests who gladly make a one off tool to make a single process easier.
The more 'correct way' than a shell script, is something simple and composable. A large unwieldy shell script that you can't make simple changes in, is terrible design, and it's a mistake to allow that inertia to gain speed.
It's not exactly a complete refutation but something I've been thinking about recently.