Automation Risks to Developer Jobs

Earlier this month I gave a talk titled "A robot will do your job one day. You should start building it." at the Develop Denver conference. The "you" in that title was other developers, and I spent the first half of the talk defending the idea that development can and will be automated. It's commonly accepted among developers that technology is making a lot of jobs irrelevant, as we're often the ones building this technology. But I've been surprised how few developers believe their own jobs might be made irrelevant by this same automation.

I think the key mistake most developers are making is misidentifying their value. When you look at job ads for developers, they're full of phrases like "strong JavaScript skills" or "experience with Agile methodology" or even "good communicator." So it's easy for developers to think these things are their value. But you can have all of these attributes and still add no value to an organization if you don't build something with these skills. And further, the thing you build needs to provide value. The value of a developer is entirely tied to the value of what she creates. The way she creates it — the programming languages she uses, the discussions she has, and everything else leading up to the end product — is an irrelevant detail. If the product doesn't add value, the developer's job is at risk.

At the technology level, this is pretty obvious to most developers. Technologies come and go quickly enough that it's clearly not a good career move to define your value based on your knowledge of Flash (which is dead) or HTML (which is already mostly automated). But more general skills like "understanding technology" are also at risk from automation. Technology doesn't need to automate your job to make it irrelevant; it can just as easily automate something else that completely changes the value of your job.

Many taxi drivers are facing this problem right now. Nobody has (yet) automated taxi driving, but they're getting hit by automation anyway. When companies like Uber and Lyft effectively automated driver dispatch, suddenly taxi drivers had a lot less value to offer. In my talk I offered Watson, IBM's Jeopardy-playing robot, as an example of this. Watson defeated human competitors, who were focused on correct answers, by being better at a completely different problem: pressing the button faster.

The equivalent for developers are risks that make software in general less valuable. Artificial intelligence is the common example in futurist science fiction, but real trends like distributed teams and API-focused architectures are already reducing the value of expertise in specific software stacks. And direct automation is happening in specific areas all the time. Building forms is a less valuable developer skill with tools like Wufoo or Google forms readily available. Wordpress makes building blogs a less valuable skill. Shopify makes developing online storefronts less valuable. There are still development jobs around the edge cases in all of those areas, but when we build easy tools that solve the common use cases, questions arise about the value of hiring developers to customize.

In my talk, I focused on defending against irrelevance by building the automation tools yourself, building the "robot" that will replace your development job. That's the only workable long-term strategy I see. But medium-term, there's another, simpler strategy: identify which aspects of the thing you're building might be hit first by automation and focus your work on less risky areas. The first step of that, identifying the value in what you're building, is worth doing regardless of the impending robot invasion. Knowing why you're writing code makes that code better.

At Aten, I'm privileged to work with a User Experience team who won't let me forget the goals driving the code I write. But many developers aren't asked to think about the why at all. If you're a developer in such a job, it's entirely up to you to ask questions and understand the true value of your code. Only you can delay robot replacements.

For more on that long-term strategy, you can watch my full "a robot will do your job one day" talk on YouTube.

Process

Read This Next