Programming won’t be automated, or it already has been

I’m afraid of a robot taking my job. I don’t care about the job part much, I’m afraid of the actual robot. To replace my job it’d need to exhibit human level intelligence. That’s scary. Before that happens though, maybe some of its infantile, and less scary, brethren can make my job a bit easier.

What is automation

It’s easy to say automation will replace jobs. But it’s not some magic wand that can just replace any job. It’s highly industry specific. In manufacturing automation means converting some raw materials, or baseline supplies, into a finished product with a bunch of moving machines sticking stuff together. In Logistics it means fulfilling, loading, and delivering that product to a customer with self-driving vehicles.

Those are both cases of getting from state A to state B. It’s easy to understand what automation. It’s replacing a very tangible process with a machine. Sure, we might keep a few humans around to babysit the machines, or just for decoration, but it’s the machines doing the bulk of the work.

This understanding is a bit of a problem for software. We do have a target product, point B. It’s the application that executes on a device (desktop, mobile, appliance, whatever). But what is point A?

We have source code already. A compiler takes this and produces something the machine can understand. It may not be an industrial looking robot, but it’s certainly a machine that transforms from A to B. As our languages become more abstract and more expressive the role of this machine becomes ever more important. Throw in some build scripts, automated tests, push-button deployment and we have a huge amount of work not being done by a human.

I’m not afraid of a compiler. Indeed, I’d love that it becomes more intelligent. I dream of a future where I get sensible error messages.

But no…

One popular interpretation of automation is that we won’t need source code. The machines will be able to “program themselves”. It seems a bit fuzzy to me, so let’s try to understand what this might mean.

Consider a person sitting in front of their computer, wishing it to do something for them. We’ll allow this person to speak to the computer, since voice recognition is a reality, even if not yet perfect. What do they say to the computer?

What if we require them to speak in structured commands, like “load this file”, “change this text to this”, or “save the file to directory A”? This is just a high-level programming language. It may be a really nice product, but it’s not something fundamentally new. It’s just another compiler. Albeit a somewhat cool one.

To be new we’d need to allow the user to make abstract requests, like “update the date in my business documents”, or “cross reference my bank statements with the expenses and report on discrepancies”. Moreso, if the goal is to produce reusable applications, we need this to be even more abstract: “Create a plugin that downloads bank statements, compares to the expense statements, and produces a standard report”.

This is the crux of programming, taking vague, abstract, and often confusing requirements and creating something usable. We need to navigate human understanding as well as a sea of technical options. Writing code is about taking those ideas and making them concrete, and useful.

This is not something AI is anywhere close to being able to do. Even us human programmers struggle to do this at times. It’s a level of reasoning way beyond the scope of what we consider automation.

Wait, you say your job doesn’t involve this type of reasoning? You just take structured feature requests and blindly transform them into code. Then yes, you will be replaced. But as a programmer you should have automated that long ago and already moved on to other things.

But yes…

There’s also a less tangible role for automation. In law it could mean using a natural language understanding, case-law searching, agent. In medicine it’s a research collation and symptom matching engine. These tools both replace some human effort, but also assist in making better decisions. This is a place where automation can shine. After all, it’s not just abstract reasoning that we do as programmers, there’s still a bunch of actual coding to do.

I’d love to see static code analysis developed more. These are tools that look at the source code of a program and find errors in it. They’ve already shown they can help find memory leaks and security holes. This can only get better as time goes on. I’ve got better things to do than tracking down obscure race conditions and memory loops.

The optimizers will also get better. Instead of working at a low-level, where they already do some amazing work, they can look higher in the code. It’d be really interesting to have my tools suggest a rewrite of a function since it’s identified it as algorithm XYZ and has a good solution.

I’m also waiting for the next generation of refactoring tools. Identifying logically similar functions and factoring out the common code is something I think an AI could do. There is plenty of refactoring I don’t do now since it’s often not worth the effort. The same automation could roll over into better source control systems that actually understand the code, not just line-by-line text.

There is so much potential, and i’ll welcome all of it.

Lots of potential, no loss

A lot of programming is already automated and there has always been a push to get more. Certainly more automation will minimize certain roles, but mainly it’ll improve productivity. Given the volumes of issues most projects have, a significant increase in productivity won’t be putting any teams out of work. It’ll just result in higher quality software.

To completely remove programmers from the equation would require essentially a human level artificial intelligence. And if I start seeing near sentient robots walking around, my first thought is certainly not going to be, “oh no, it’s going to take my job!”

Originally published at mortoray.com on March 22, 2017.