>The automation of tasks that formerly required writing software, are automated by someone writing new software.

This.

User timr writes:

"Then take a close look at AWS, Heroku, Rackspace...those were all systems engineering jobs. Startups don't have to hire people to do that now. What used to be thousands of jobs is now maybe a tenth of that."

Let's take this point and unravel it a bit. AWS is hugely disruptive. It takes work previously done by operations folks (like me) and puts useful tools directly in the hands of users (programmers).

This is a huge change that increases a programmer's efficiency. (I prefer the term developer, but I'll keep it to stay consistent). In effect, it has removed one of the major barriers to entry, that is, getting your code online and accessible from the internet.

So automation is the thrust of the argument; robots on the assembly line replacing auto-workers jobs. Someone had to build those robots.

In the programmers case, that someone is a programmer.

So, what can we learn from all this?

Change is good. We need these disruptions to setup the next growth phase. Software is different. The barriers to entry are being removed. Productivity increases as a result.

Be on the positive side of the change. Predict, plan, strategize, and stay relevant.

Happy Labor Day.

Great point. The nature of the work changes as old complexity is automated away, and new growth possibilities arise as a result.

Good point - what we do is not the visible coding; only a small 10-20% of our time is doing that. It's the 80-90% that is thinking, the considering and discarding of solutions that is valuable and not easily automated.

A good point, but an obvious one to economically-literate readers. The counterpoint to it is that it requires fewer developers to automate a process than it requires to write it. In the short run, unemployment may increase, but in the long run, it'll stabilize.

> The counterpoint to it is that it requires fewer developers to automate a process than it requires to write it.

Not by definition. Rather, only once it becomes easier to automate than to do by hand, we automate.

The first part is technically true - the automation team can exceed the original team, but this may be a special case of "engineers untangling a mess of functionality accumulated over the years." The second part has an exception of its own - there doesn't necessarily have to be a complexity threshold, developers "over-automate" simple processes all the time (e.g. Microsoft).