Disclosure: I may earn affiliate revenue or commissions if you purchase products from links on my website. The prospect of compensation does not influence what I write about or how my posts are structured. The vast majority of articles on my website do not contain any affiliate links.
This post has nothing to do with the sea
I’m really into automation. I’m of the opinion that the media spends so much time highlighting hypothetical Artificial Intelligence scenarios instead of the concept of automation because the sci-fi scenes that accompany AI help distract us from the bleak reality of well-designed automation. What I’m saying is that, sure, one day AI actually might be an existential scourge. But automation already exists, able to eliminate millions of jobs and plunge us into a dystopian reality where many peoples’ livelihoods are replaced by machinery or software.
I just wanted to get that off my chest. If you work in or around software, you know that most tasks can be automated. There are entire business segments that could not exist without automation. Even at companies that specialize in software, though, there are always tasks yet to be automated. There are still bits of human reasoning that can be reduced to code and run without any human intervention.
So, if there is still stuff to automate, and you know how to automate it, why not just go for it? The main guidance many people will rely on is the flowchart below. Basically, it helps you calculate the ROI of automating a task.
The chart is something I’ve referred to often, but it is flawed in that it centers on one aspect: time. Why else might one say no to automation–what reason is there to pump the brakes and not jump in head first?
Loss of Expertise
When you automate a task, you gain some time that you can use to do other things. In a perfect world (which doesn’t exist), there is a (semblance of a) guarantee (depending on how complex the system is) that the task will get executed. Once you’re sure that the task is worth automating from a time perspective, there is another consideration to make.
When you automate a task, you code the behavior you were previously executing by hand. The task will run once, twice, maybe tens of thousands of times. When you watch it run for the first time, you’ll still have a solid grasp on what’s going on behind the scenes. As time goes by, though, you won’t be thinking of it as much. If everything runs perfectly and you never have to debug an errant failure, maybe you’ll never have to worry about it again. Depending on how pertinent the task is to your day-to-day duties, you’ll eventually forget how to do it.
This is automation-induced brain-drain and it’s a funny thing. Interesting in theory, but has anyone decided against automating for this reason alone? Yes. I have heard of people not being permitted to automate copy-and-paste jobs because it was deemed important that those employees look at the numbers being transferred between documents and retain intimacy with where the numbers came from.
I have experienced situations where the manual execution of a task was a thorn in my side. It wasn’t particularly taxing, but it often interrupted the most productive period of my day. I automated it. The more esoteric details of the task began to fade from memory. Weeks went by and everything seemed fine. However, there was a lot of knowledge that overlapped with other processes, some of which weren’t automated. Whenever–however infrequently–I had to debug issues with those processes, I was wishing I could better recall the details of the process that was now being completed automatically.
Maybe this is significant to me because my brain works in a particular way. But, when extrapolated (or when the maintainer leaves the company), you risk losing valuable expertise and greatly increasing the risk of misfiring while debugging.
Magnitude of Risk
I’ve spent my entire adult life working in high-frequency trading. Some call it automated trading. Some call it algorithmic trading. The point is that (many–most–a significant amount of) trades are being conducted in an automated way. Not necessarily faster than a human can react, but in a systematic way.
As you might imagine, when you automate a task that handles financial transactions, there are major risk considerations. It’s one thing for a manual trader to misclick a price and then have to dump a position for a loss. It’s several orders of magnitude riskier to have a bot with a bad piece of logic make hundreds of trades before someone notices and turns it off (this is what caused Knight Capital to implode).
When it comes to trading, defense, or really any industry where lives or piles of money are on the line, to automate means to construct entire departments around the proliferation, safety, maintenance, and operation of what’s been taken out of human hands. While these examples are among the most complex, any automation carries risk, and proper risk management procedures must be taken into consideration when evaluating feasibility and ROI.
Automating Yourself Out of a Job
Kind of funny, kind of sad, kind of true. Over the years, I’ve read many stories (on Reddit) from people who worked menial office jobs, learned how to program, and automated the majority of their work. It’s an intriguing ethical debate. If you are hired to work a job and you end up automating it and collecting paychecks while you play Runescape at work, should you feel bad? Is it wrong, fraudulent, or just a bit disingenuous?
If you’re already a software engineer, can you automate yourself out of a job? In terms of designing or implementing new software, no. Emphatically. But when it comes to automating processes, the answer is yes. The mantra driving DevOps is that your job is to eliminate your job. To reduce a team’s toil to the point that a single overseer who monitors the fluidity of a complex system as it churns through stimuli. This brings about an odd contradiction. DevOps Engineers are some of the most desirable employees to have, yet they’re even more desirable to let go. Because, if you can tell a DevOps Engineer that it’s time to move on, he’s probably accomplished a hell of a lot.
In researching the careers of some of the most successful DevOps engineers, I’ve noticed that some of the most prolific make their livings as consultants. This makes sense. It might only take a year for an entire company to get upgraded to a modern DevOps approach. Rinse and repeat. There isn’t anything wrong with DevOps Engineers who stay employed on a more consistent basis. Most end up heavily involved with reliability work (similar to a Google SRE) and, if not, many companies that are aware enough to understand the need to employ DevOps Engineers probably have a solid pipeline of exciting projects and initiatives to keep them busy.
If you’re too good at automating, you might find yourself out of a job. But in a world where automation reigns supreme, this is a badge of honor. Just don’t be afraid to pump the brakes.
