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!”

Categories: Culture, Editorial

Tagged as: , ,

11 replies »

  1. > I’d love to see static code analysis developed more.

    Rather than trying to generate semantics from code, it’s much much easier to generate code from semantics.

    With the FOAM project, we’ve found that we can typically generate 80-98% of the code for most applications from high-level models. We don’t aim at a 100% solution, just like how most factories are not 100% robotics.

    • I totally agree that code should be generated from semantic which in turn can be deciphered/extracted from any source (think about the evolution of NLP)

    • This is still just code, albeit a higher level form of code. I agree the languages we use to program will evolve, but they’ll still be specialized languages.

    • This reminds me of F# TypeProviders. They’re pretty powerful and can lower the amount of how much you need to generate your own types. And they can tell you if something has changed since the last time you opened your code. You can even right plain SQL in your IDE and it will tell you as you type if you wrote your query correctly.

      F* has some interesting features too. It will basically let you write some of your tests in your code and it will complain as you type if you aren’t adhering to your “tests” and writing faulty code.

      Unfortunately, it takes a lot of work to get people to move to new languages that are much more developer friendly and powerful.

  2. I enjoyed reading your thoughts — similar to mine, I’d say. One of the areas I’m interested in is improving the re-use of software, all the way from “iterate over the lines of a file”, up to larger chunks. In a sense, programmers have been automating their jobs for decades. But one of the things that impedes progress that that there is a tremendous amount of waste in software development — some functions have probably been implemented 10,000 different times by programmers, and some 1-5 line chunks of inline code have probably been written millions of times by programmers. If we can find a natural-langage-ey way to instantly find that already-written and already-code-reviewed code and get it into our editor so that we can make a couple tweaks, then we’re much better able to make use of that existing “automation” — ie. already-written-code.

    • Resuse is a challenging area. All those bits of code tend to something slightly different, or expose a project-tailored API.

      A standard library serves the primary role of code reuse. As we see though, it takes a long time for code to elevate to this level, being reserved for the truly universal cases.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s