> Automation not only saves you time, it changes what you do.<p>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.
Something that seemed somewhat implicit in this article, but never fully stated, is that it also increases <i>the quality</i> of the work, or in other words, decreases the probability of bugs and errors. Every time you do a manual process, you introduce the possibility for a lot of human error. That's where a lot of the "willingness" vs. "unwillingness" comes in (aside from just the "time" aspect, or partially as a <i>cause</i> of the "time" aspect). The more boring the task, the more likely you are to sleepwalk through it and not be thorough in checking things. This leads to bugs, and can either (ideally) increase the time of the task since they immediately surface and then you are "shaken awake" and have to dig around for what you mistyped, or in the worst case, go in undetected. Like everything computers do, and kind of the whole point of programming, a script can go into the task with the same "willingness" every time. That weird edge case you found when you did the task the first time when it was still interesting can get coded in and checked for. Future weird bugs can then be trivially added to the automation script vs. just noted as a "WARNING" in a README that will never get read. If there's no existing tool, then the activation energy to create that tool just to account for that weird thing that happened that one time is always beyond the "fuck it, let's just make a note" boundary. As such, it's best to just bite the bullet in the beginning. The unfortunate thing is that this is really a indictment of our workflows in general. Much of what we do is so close to programming as it is, it sucks that "putting it into a literal program" can be such a chore (and it very much is).
Another thing is - automation is documentation. It might just be three 1-line bash commands that you have as muscle memory that you do once a week - so there's no time save.<p>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.
As you make something cheaper demand for it goes up. Easy to forget about it when you try to calculate the value of automation. I'd say in most cases automation pays off if you do it properly, not to do the intended task but to do all the unintended tasks, reusing the automation code for later, reducing errors from manual work and opens up doors for new product design paths in the future.<p>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.
>This is an example of an unethical interface. One week of programmer time would have easily saved multiple weeks of designer time...<p>>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.<p>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.<p>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.
> Cakelisp was a revelation because it was my chance to escape from these limitations. I had to pay my time in order to make something I consider better, but it was absolutely worth it. I was now in charge of the interface. I shaped the language, the language didn't shape me.<p>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.
As a UX practitioner with engineering experience, I'm happy to see an article like this, but also a bit disheartened that in 2021 it's still a revelation for many that frustration, satisfaction, and cognitive load are key considerations in prioritization in addition to raw efficiency.