The Happy Demise of the 10X Engineer

Whatsapp had 450 million monthly users and just 32 engineers when it was acquired. Imgur scaled to over 40 billion monthly image views with just seven engineers. Instagram had 30 million users and just 13 engineers when it was acquired for $1 billion dollars.

This is the new normal: fewer engineers and dollars to ship code to more users than ever before. The potential impact of the lone software engineer is soaring. How long before we have a billion-dollar acquisition offer for a one-engineer startup? How long before the role of an engineer, artisanally crafting custom solutions, vanishes altogether?

As the leverage of the individual software engineer increases, the barriers to becoming a code creator are falling fast. The same software foundation (open source software, development tools like Github, infrastructure as a service provided by the likes of Digital Ocean, and more) that allowed Whatsapp and Imgur to scale, means that experience and skill writing software become less important.

An individual can now scale a web app to millions of users with Digital Ocean, Heroku and AWS (perhaps coordinated by Mesosphere). It no longer requires a sophisticated understanding of MySQL parameters to scale a database on Google App Engine, just as it no longer requires a knowledge of the CPU chip it’s all chugging away on.

How long before we have a billion-dollar acquisition offer for a one-engineer startup?

The way to describe this software coding continuum might be pre-foundation – where in its extremist form, every piece of software started in Assembly — and post-foundation – where software is like Legos, just snap the pieces together.

Pre-foundation, even the simplest tasks took a tremendous amount of knowledge and labor, because you had to build up from the bottom. For a website this might have meant (going up the stack) a server OS you patched and managed yourself, running your homegrown or hand-tuned web server, caching system, database, account management system, rendering engine and front-end libraries, with your own hand built analytics platform, build process and bug reporting tool. If that sounds like a lot of stuff to manage, that’s because it was.

Post-foundation, one need only focus on the user-facing function at hand, working with only one level of abstraction. It will one day be laughable that building Facebook required tuning web server software, let alone building entire data centers. The other layers of the stack will be abstracted away entirely and writing software will continue to look more like assembling a collection of Github-hosted libraries and APIs.

We are now, thanks to the web and the open source community it created, rapidly hurtling towards a world with a software foundation. We are building a common core of software tools and platforms that allows one to write less code, accomplish more, and reach more users. We are moving towards software as Legos.

And yet, despite all of the tremendous progress, we are still in the beginning of this transition. Here is Brad Cox, the creator of Objective-C, writing 24 years ago:

Mature industries like plumbing are less complex than ours, not because software is intrinsically more complicated, but because they—and not we —have solved their complexity, nonconformity, and changeability problems by using a producer/consumer hierarchy to distribute these problems across time and organizational space. The plumbing supply market lets plumbers solve only the complexities of a single level of the producer/consumer hierarchy without having to think about lower levels, for example, by reinventing pipes, faucets, thermostats, and water pumps from first principles.

While Cox wrote this before Linux and Stackoverflow, he is still right. The modern engineer, while blessed with libraries and frameworks that remove complexity in order to focus on the problem at hand, is still constrained by the need to walk up and down a ladder of abstraction levels. Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy. All require the creator to leave his or her rung on the ladder of abstraction.

But we are getting there, and software is eating software development. The foundation of open source based software platforms, infrastructure, knowledge and best practices continues to grow. I bet Stackoverflow alone has increased programming productivity by a few percentage points. Now add fifteen years of free or inexpensive developer tools (Github, too many IDEs to list), automated infrastructure (Mesosphere, AWS, Google App Engine, Heroku, DigitalOcean and more), databases (MySQL, MongoDB, PostgreSQL, Firebase and more), high level languages (Python, Ruby, PHP and more) and frameworks (Meteor, Angular, Django, Rails, Bootstrap and more): the faucets, pipes and water pumps of programming. All rooted in open source and all removing levels of detail that a creator making software for users shouldn’t have to care about.

Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy.

Now, what does this mean for the 10x engineer? The “10x engineer” is still needed to build the foundation — building AWS or Mesos remains very difficult. But as we build out the common foundation, the skill and experience an individual needs to accomplish a task on top of the platform decreases.

A “10x engineer” is, afterall, an incredible misnomer. A 10x engineer is not necessarily 10 times more productive — they are just “next level” better engineers who in some contexts are 1.5x and sometimes 100x better, depending on the difficulty of the task and leverage of the outcome. But post software foundation, when software looks more like Legos and less like artisan craftsmanship, the relative output multiple of the “10x” engineer working on top of the foundation moves closer to one.

Thus software itself becomes the driving force of leveling the ability to write software to solve problems. This is a good thing: As software becomes a high-impact, low-skill trade, we decouple the technical ability and experience needed to write tricky software from the ability to solve problems for people.

We begin optimizing success for problem solvers and business builders, not those who happen to be both these things and have been programming since age 12. We unleash new categories of startups, from builders with new backgrounds and perspectives. We unleash thousands of new startups that can now be built because this friction is gone. And while we’ve been primarily talking about the web here, we’re already seeing the same phenomenon begin to happen in big data, bio-computation, artificial intelligence and other fields.

Today, if you have a great idea for a software product, you need to either be an engineer or find one. Tomorrow, that billion-dollar startup acquisition might not need an engineer at all.