This bears repeating. When you automate a task, you often push it over a "breakpoint" where it suddenly makes certain things profitable in terms of effort. For example, say you fill up a water bottle and place it within arm's reach, instead of running to the tap every time you're thirsty. You save maybe 10 seconds per sip, but the real win is that you can now consider behaviors like "drink water every 5 minutes" that previously you would have considered too much effort.
To take an example from operations: To me (admittedly speaking from the developer side of things), the overwhelming benefit of containerization has nothing to do with elasticity or scaling or really any of the marketing buzzwords. The real benefit is that Docker and friends encourage presenting a much more consistent management surface to the operations team. In the short run, this is just the price of automation. In the long run, this greatly reduces the mental burden of understanding how all the individual pieces are configured and deployed.
Most of that was never anything but incidental complexity. I doubt that ops's job has actually become any easier over the past 20 years. But, even so, if they're spending less time just shaving yaks, that suggests that a greater proportion of what they're doing is genuinely valuable.
I've worked with plenty of wizards that can figure anything/everything out, but these deviations have a hidden cost.
The farm of resources no longer behaves like cattle, it's all pets - with their own identities, personalities, etc.
Containers abstract most of this away, a simple runtime and any host can be just like another with a tiny amount of automation.
We get things like scale from this, but if it 'works on your machine' but not ours, we're no further.
This happens when the person that uses the automation no longer needs to learn how to do the task.
Teaching people is actually extremely expensive even if you forget about reliability of entire process.
People have limited ability to learn stuff. So being able to automate certain tasks not only allows people to do more in less time or do it better, it can actually allow doing more things that the person would ever be able to learn, without need of learning.
But automation will save you a lot of time and stress if you had long vacations or worked on a different project for half a year. Suddenly the muscle memory isn't there and you have to learn the hard way AGAIN if it's not automated.
This assumes that you actually own the product, if you don't own the product and just have a job to do then why bother about saving time, so in this case you should still automate it because automation is more fun.
Then I cut it to 7 minutes, saving an additional 30+ minutes, because everyone was now running the build 4-5 times a day.
What I really saved was wasting each other’s time and goodwill by reducing the frequency and severity of people checking in broken code that blocked everyone else. Because they were expected to test more often, and they made smaller commits because it wasn’t so painful.
- if you can do something more quickly you might also choose to do it more often
- automation can reduce human errors
- once something is fully automated it can be used as a building block in a larger piece of automation
I can think of one more:
- automation can make it easier to hand over work to someone else, or increase the number of people who are able to do it
But also one disadvantage:
- automating something can lose a human "sanity check" (for example, you could generate reports full of missing data and maybe nobody will notice for a while)
Any more?
Yeah, you shouldn't automate things that you don't know how to automate. Don't use ML for automation for example.
>When developing things which have a human interacting with it, you should consider how much you value your life time, and have empathy for your users' life time.
Well articulated. Outside of software and technology, people have to use software tools that they have little control over - tools assigned for their job. When authors take the time to understand how their tools are used, it can have a profound impact on the daily work for a huge number of people.
For example, I interact my electronic medical records system between 2-5+ hours each day. To write a document requires 15 mouse clicks, with a 1+ second load time after each click. It's painful. I would use the author's words to describe this as an unethical interface. If the devs who wrote this software had to use it for their daily work, I imagine that they would demand new tools or leave in frustration. But for us, as users without a choice, it contributes to dissatisfaction at work and ultimately to burn-out.
Often those devs have subpar development environments too and don't know to look for better or does not have the skills/time to up level themselves.
We are tool makers, making tools that we use in tool making so that the act of making tools for our tools is more enjoyable.