An old post gets a companion: Automate and win (2018-03-22).
There was a tweet today by Kelly Vaughn that poked right at the heart of the insane drive to automate work—a drive that I take quite often...
Why spend 8 minutes doing a one-time task manually when you can spend 2 hours attempting to automate it?
— Kelly Vaughn 🐞 (@kvlly) April 28, 2020
To automate—perchance to save time: ay, there's the rub. I offer no solutions. If the problem is understandable or well-defined like a factory process, you can analyze the time, money, etc., to get a value for the efficiency gained. For the smaller problems that bother you or your team, the calculations are fuzzier, especially when you're faced with a software problem that is going to require some sort of software solution, especially when you know in your heart that the solution is going to be high on the hack-scale and low on the maintainability-scale. Then it's a matter of taste to decide whether or not to figure it out. Engineers especially like to have their problems with discrete solutions, but the truth is that you have to consider in addition to what your team at work will gain (or lose), that you might get something out of the deal for yourself in what you learn from the task, and how much of your own time you're willing to give to it.
And so on. Yet sometimes automation is a puddle of water that, once you step in it with the casual confidence that it won't even wet your laces, is actually ten feet deep. If your team has any common sense, they'll pave over that hole before you can climb out.
Randall Munroe of xkcd knows—here are a few of his own takes on the perils of automation:
- 974: The General Problem
- 1205: Is It Worth the Time? (actually this one has an analytical kind of solution, if that's something that you Need)
- 1319: Automation