6 ms·

Not the autoworkers of our generation

81 points by imsky 13y ago

tedsanders 13y ago
I'd like to talk about the claim that high-skill work is less likely to be automated than low-skill work. The author says: >On almost all points, Baugues misses the mark. First, there is a qualitative difference between an auto worker (unskilled manual work) and a software developer (skilled knowledge work) that made automating the former inevitable. As a rebuttal, I would point to some passages from Martin Ford's book on automation, The Lights in the Tunnel: >A common misconception about automation is the idea that it will primarily impact low paying jobs that require few skills or training. To illustrate that this is not necessarily the case, consider two very different occupations: a radiologist and a housekeeper.... >In fact, we can reasonably say that software jobs (or knowledge worker jobs) are typically high paying jobs. This creates a very strong incentive for businesses to offshore and, when possible, automate these jobs.... >As a result, we can expect that, in the future, automation will fall heavily on knowledge workers and in particular on highly paid workers.... In general, I think knowledge jobs are at greater risk of automation than manual labor jobs. Robots are expensive. And they also don't scale as well as software. It's no coincidence that the largest software companies dwarf the largest robot companies. Ultimately, because software can scale, it becomes ridiculously cheap when you deploy it to millions or billions of people. I agree with your overall point that creativity and design are hard to automate. However, software jobs are being and will be automated. What matters in the end is whether automation increases or decreases the overall demand for development. I.e., whether software automation is a complement to labor or a supplement to labor. So far, it's been a complement and software productivity has skyrocketed over the last couple of decades. This trend seems likely to continue, but who knows what the future holds 100 years from now. P.S. Another industry that evolved similarly is agriculture. At first, tools and animals made farmers more productive, and farmer employment rose. But eventually, productivity rose so high that farmers started to saturate demand. Today, only 2% of Americans are farmers, despite farmers being the most productive of all time. So what's the moral here? What can software learn from farming? I think the moral is that quantity supplied is a function of both SUPPLY of labor and DEMAND for labor, and you can't ignore one when you predict the future. P.P.S. You probably realize that the weakness of the agriculture comparison is that the hunger for food is far more easily sated than the hunger for software. The first has a biological limit, whereas the second is ostensibly unlimited. Therefore, you might reason, higher productivity in software is less likely to saturate demand and reduce employment. However, I would caution that some software demands might be easily saturated. Consider a company that wants its own website and app. If websites and apps become 100x cheaper (as a result of automation/higher productivity), would businesses demand 100x as many? Probably not. P.P.P.S. Not all manual labor is created equal. Repetitive, indoor labor is much easier to automate than non-repetitive or outdoor labor.
- imsky 13y ago
  Ford's point is a good one, but it's a bit dishonest. A radiologist's job is processing information - it's easy to move overseas or stick into an algorithm. A housekeeper's job is managing a house and the people living in it - a hotelier is similarly difficult to automate. Regarding your PPS - it's not so much that demand for software is unlimited, it's that software can be used for far more purposes than food or natural resources. A single algorithm can be used in multiple industries, and given that the world doesn't develop evenly as a whole, there will be software opportunities in the real world (machinery), in processing the real world (commerce), in the virtual world (media), and in processing the virtual world (analytics), and these opportunities will increasingly require more and more knowledge and creativity.
  - tedsanders 13y ago
    What's dishonest? I don't think I follow. Do you mean that housekeeper and radiologist were cherrypicked and that in reality laborers are at higher risk of automation than knowledge workers?
    - imsky 13y ago
      No, this part: "A common misconception about automation is the idea that it will primarily impact >low paying< jobs that require few skills or training. To illustrate that this is not necessarily the case, consider two very different occupations: a radiologist and a housekeeper." A hotelier's job, the well-compensated version of a housekeeper's job, is also difficult to automate. On the flip side, a good deal of information processing jobs, no matter how well compensated, can be automated. I think the point was made rather bluntly, without elaboration.
      - nrivadeneira 13y ago
        The point was made just fine. He said that there is not one definitive compensation class that will be primarily affected. It doesn't seem like you've refuted that.
      - 13y ago
angersock 13y ago
As much as I'd like to agree with the author, the case stated is pretty holey. To pick on the "We'll never be automated example": It's not that one day programs will write programs that write--oh wait, that's already happened. It's not that tools will come around that making throwing up a simple website with ecommerce functionality ea--shit, that happened too. It's that the core functions of software, from a business perspective, are pretty much nailed down now. It's that the average dudebro with an MBA and half a brain can throw together an MVP and start getting market feedback. It's that the homeless guy who lives down the street from me can publish an ebook from his acer. The thing that we all love so much, the removal of gatekeepers and democratization of information capital? Yeah, so, that thing is what will put us out of jobs. And that's fine. The thing the author misses is not that there won't be a few gigs around for people who need to optimize their database backends and red-black tree all the things and skiplist their twitters--it's that the vast majority of things that used to require people to find a coder to help them are now a few buttons away. Oh, and also that we've cultivated a user base so ignorant and attracted to simple glossy black boxes that they can't appreciate what it is to have a real engineer along for the ride anyways, nor how to usefully communicate with them if they had one. That's going to sting too.
- imsky 13y ago
  We do have programs that write programs. Who's using them? I like your optimism, but the average guy with an MBA definitely can't throw a MVP together, especially not in 2013 when the low hanging fruit have been steadily picked off. The bar is continuously being raised, and it'll be cheaper for the MBA to hire a developer to throw that MVP together, using highly complex and abstract components. If I'm getting the second half of your reply right, you're saying it's the availability of high-quality low-complexity zero-cost solutions to mundane problems that's going to put software developers out of a job. But that's exactly what I address in my post - these things were going to be automated anyway. And don't be disappointed by a user base attracted to glossy boxes - some of them will get curious eventually.
  - timr 13y ago
    "We do have programs that write programs. Who's using them?" If you count things like Weebly, the answer is: a "whole bunch of people", heading rapidly toward "everyone". Not that long ago, every Weebly customer would have meant a programming job for someone. That kind of work is gone. 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. "the average guy with an MBA definitely can't throw a MVP together" You're wrong. It happens all the time. It happens so often that's a cliche. You can't go to a meetup in the valley without being assaulted by ten brohans looking for "feedback" on their "MVP". The important thing to realize is that the need for software engineers doesn't scale with the maximum complexity of software projects; it scales as a function of the average complexity: think of a bell curve, where the X-axis is "complexity", and "need for engineers" is the area under the curve to one side of some vertical line. We keep moving that line further and further toward greater complexity. So far, the distribution has shifted to keep up, but there's no guarantee that will keep happening. Are we going to need people to write complex, novel software in 2050? Absolutely. Will we need more people than we need to write complex, novel software today? That's not a question with a predictable answer. It might well turn out that the "average" programmer (say, the ones who know how to use Rails and jQuery and are fond of complaining about interview questions involving algorithms) is a doomed creature.
melbourne_mat 13y ago
It's a pretty complacent article. How long until software development has good quality automation - of a kind that drastically reduces the number of jobs? I suggest it's not as far away as the author thinks.
- imsky 13y ago
  We've had the tools to automate software development for years and there's been almost no movement in that direction.
- dreamfactory 13y ago
  Software generation is automated but when people are talking about software development they mean (technical) design. Design isn't a commodity or product but a one-off process and therefore by definition cannot be automated. The underlying topic isn't about automation of software development - it's about buy vs build, and as ever that depends on specific requirements and circumstances.
- wvenable 13y ago
  That's the wrong question. The very nature of software is automate jobs including software jobs and has since the very beginning. A programmer today is easily one or more orders of magnitude more productive as a programmer 20 years ago. We're all producing much more software with fewer people. The question is when will the demand for software be low enough that this ongoing process will reduce the number of programmer jobs.
jimbokun 13y ago
I feel like neither the article, nor any of the comments here so far, mention a very obvious point. The automation of tasks that formerly required writing software, are automated by someone writing new software. This should be the normal, everyday experience of the software developer. Take the software you wrote yesterday, and write higher level software on top of it today to accomplish things you couldn't before. So automating the software jobs of yesterday out of existence will require the software jobs of tomorrow. As for the computers writing their own software, that strikes me as indicating the Singularity has arrived, in which case all human jobs will be obsolete.
- imsky 13y ago
  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.
  - eru 13y ago
    > 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.
    - imsky 13y ago
      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).
- dmourati 13y ago
  >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.
nrivadeneira 13y ago
Regardless of which article is correct (this one or the one it is referencing) in predicting the future of software employment, I think we'd all do well to keep an eye out for the future and be agile and ready enough if a Detroit-like situation does arrive. It should never be taken as a given that we'll always be highly sought after and well paid. With that in mind, I find Baugue's article much more useful considering I've never thought of an article that can be reduced to "Things are great, I don't think anything will change." to be of much help.
- imsky 13y ago
  That's a gross oversimplification of what I wrote. If you take only Baugues's conclusion ("don't be reckless, save and network, things may not always be so great") and ignore his premises, you're reducing the article to a platitude. My intent was to show how fears of automation are nothing new and should not stop developers from pursuing their careers.
clarky07 13y ago
Interesting that one of his examples, Wordpress, has contributed to lots of software jobs as well. Writing themes, plugins, etc can be fairly lucrative and probably more interesting than making a blog from scratch over and over. The whole point of writing software is to make it so you don't have to keep doing the same thing over and over. That doesn't mean there aren't new things to do. Software really is eating the world. If we run out of software jobs, it's probably because we've automated literally everything else already.
- imsky 13y ago
  That's a good point - there can be serious career opportunities in managing, supporting, and modifying ostensibly "automated" solutions. The core may be automated, but the ecosystem doesn't have to be.
Spooky23 13y ago
Software people are so arrogant. Auto workers arent and weren't unskilled manual labor.
michaelochurch 13y ago
There is something that can slaughter the job security of software engineers, but it's not technological advancement. Before I get to that, my personal forecast is: income expectancy for intelligent and hardworking people will continue to increase but so will variance. Eventually, the variance will become intolerable enough (sans regularization) that basic income will appear to be the only solution; even the smartest people will see a personal need for something like it. There will be a lot of struggling and fighting over implementation (e.g. do college graduates get more? how about families? should society incentivize or penalize reproduction?) but everyone will agree that it's necessary. That's probably about 30-50 years from now. Okay, so what's the #1 threat to software developers' job security? Not robots. We have robots that write code (compilers) and our jobs are still challenging. Instead, it's upper-level complacency in society. An elite that would rather hold position and keep relative rank than grow society and gain absolute prosperity (but at a lesser rate than others, losing rank). Historically, this is the norm for elites. Many people, especially in positions of power (because power selects such people) would rather reign in hell than serve in heaven. If they can conspire toward self-protection and social mediocrity, they will. The good news is that, in a large and heterogeneous society, it's actually very hard to hold any conspiracy together for very long. This is why conspiracy theories overstate the power of such organizations; conspiracies (lower-case 'c') exist all over the place (e.g. Davos assholes) but none have the power to run the world unilaterally. It's too chaotic and large. Societies and nations have set themselves back centuries when their elites conspired toward mediocrity, but I don't think the world elite is capable of doing so-- especially not now. If the global business elite figures out a way to conspire toward mediocrity, the people like us are fucked, because excellence will cease to matter and being good at what one does will just get one the reputation of a troublemaker. However, the likelihood that anyone could pull this together in a world with unprecedented distribution of technical literacy is incredibly low. As long as there are people looking to do things in this world, and the world continues to advance technologically, there will be a high level of demand for people who are technically competent. We might be applying our skills differently and changing industries, but there will be work for us, and society would have to reach an advanced (that is, certainly plausible but unlikely) state of degradation for us not to do that work on at least half-decent (e.g. middle-class) terms.
- 13y ago
wildgift 13y ago
Autowork in the 1930s and beyond may have been semi-skilled, but before widespread automation, it was a craft, and cars were expensive. This de-skilling has always been happening in software. Back in the 80s, word processors were written in assembly. Today, they can be written in JavaScript.
wildgift 13y ago
Aren't programmers more like the engineers who made the cars? Their work product is not just the design but the assembly line and the process, and those things help produce parts and cars. The autoworkers are more analogous to the people who work within software-controlled workplaces. That would be the people who pack boxes at Amazon.com, or do data entry, or customer support.
kamaal 13y ago
It will be too arrogant on our part to think we can't be automated. If you have used eclipse over the years you will see the kind of gradual automation happening there. Its not the kind of automation that produces code automagically all alone by itself. But software like eclipse pulls the barrier to entry too low to a point even people who understand nothing much about Java or in general about software can comfortable contribute to make a living out of it. And eclipse is only getting better with time. These days you can pretty much code complex Java application without even reading a book. I guess very soon, software like eclipse will fill-in-code-blocks as we express a intention. And then our job will be to stitch those blocks. This is what is dangerous. And this kind of thing has the potential to drive the supply up very quickly. Thereby the wages decline. There is no 1-1 mapping, between a automaker and programmer. But the theme is very common. I am even damn sure we will soon make software a commodity to a point when people can think in terms of abstract software blocks. Just like how a common man can today think of a car in terms of engine, clutch, gear etc.
- rimantas 13y ago
  > If you have used eclipse over the years you will see the > kind of gradual automation happening there The programmers job is not to do the things that eclipse can do. It's doing the things that he could do on paper, or just in his mind. Automating programming is like automating composers, writers and actors. Possible, but hardly desireable.
mseebach 13y ago
Both articles misses the mark. There are still autoworkers out there, just not in Detroit (OK, there are less of them, but they're still there). Autoworking didn't fail, Detroit (ie "big auto") failed. And they failed because they spend all their energy building moats (trade policy, emissions policy, unions etc) rather than improving and innovating (like the asian auto companies excelled at and the european ones partly kept up with), so when the house of cards came down, it came down hard. As long as we (software engineers) don't sequester ourselves wholesale in a homogenous monolith but continuously keep up with innovation, we should be well equipped to respond to changes in the market in time. The first article touches on this in the last paragraph, but I'm not convinced it's for the "right reasons".
- ams6110 13y ago
  The rote, unskilled work in auto assembly was easily automated (apply a spot weld here, insert a part there) but a lot of the skilled work was as well. The precision parts in automobiles used to be made by hand by machinists. This was highly skilled work, and it's now almost entirely been replaced by CNC. Machinists today, to the extent they still exist, are much more like programmers. They are still used for small and one-off jobs, but mass production of machined parts is programmed directly from the designs now, so you don't need a machinist in the picture at all for that. No amount of keeping up with innovation would have helped there.
  - mseebach 13y ago
    If those people were let go (or retrained) continuously as they became redundant, instead of being employed in a unsustainable behemoth which then collapses all at once, they are much better positioned to re-qualify and re-join the workforce (maybe in the same, maybe in a different company) in a higher-skilled position. This could happen multiple times over a career.

81 points by imsky 13y ago

I'd like to talk about the claim that high-skill work is less likely to be automated than low-skill work. The author says: >On almost all points, Baugues misses the mark. First, there is a qualitative difference between an auto worker (unskilled manual work) and a software developer (skilled knowledge work) that made automating the former inevitable. As a rebuttal, I would point to some passages from Martin Ford's book on automation, The Lights in the Tunnel: >A common misconception about automation is the idea that it will primarily impact low paying jobs that require few skills or training. To illustrate that this is not necessarily the case, consider two very different occupations: a radiologist and a housekeeper.... >In fact, we can reasonably say that software jobs (or knowledge worker jobs) are typically high paying jobs. This creates a very strong incentive for businesses to offshore and, when possible, automate these jobs.... >As a result, we can expect that, in the future, automation will fall heavily on knowledge workers and in particular on highly paid workers.... In general, I think knowledge jobs are at greater risk of automation than manual labor jobs. Robots are expensive. And they also don't scale as well as software. It's no coincidence that the largest software companies dwarf the largest robot companies. Ultimately, because software can scale, it becomes ridiculously cheap when you deploy it to millions or billions of people. I agree with your overall point that creativity and design are hard to automate. However, software jobs are being and will be automated. What matters in the end is whether automation increases or decreases the overall demand for development. I.e., whether software automation is a complement to labor or a supplement to labor. So far, it's been a complement and software productivity has skyrocketed over the last couple of decades. This trend seems likely to continue, but who knows what the future holds 100 years from now. P.S. Another industry that evolved similarly is agriculture. At first, tools and animals made farmers more productive, and farmer employment rose. But eventually, productivity rose so high that farmers started to saturate demand. Today, only 2% of Americans are farmers, despite farmers being the most productive of all time. So what's the moral here? What can software learn from farming? I think the moral is that quantity supplied is a function of both SUPPLY of labor and DEMAND for labor, and you can't ignore one when you predict the future. P.P.S. You probably realize that the weakness of the agriculture comparison is that the hunger for food is far more easily sated than the hunger for software. The first has a biological limit, whereas the second is ostensibly unlimited. Therefore, you might reason, higher productivity in software is less likely to saturate demand and reduce employment. However, I would caution that some software demands might be easily saturated. Consider a company that wants its own website and app. If websites and apps become 100x cheaper (as a result of automation/higher productivity), would businesses demand 100x as many? Probably not. P.P.P.S. Not all manual labor is created equal. Repetitive, indoor labor is much easier to automate than non-repetitive or outdoor labor.

imsky 13y ago
Ford's point is a good one, but it's a bit dishonest. A radiologist's job is processing information - it's easy to move overseas or stick into an algorithm. A housekeeper's job is managing a house and the people living in it - a hotelier is similarly difficult to automate. Regarding your PPS - it's not so much that demand for software is unlimited, it's that software can be used for far more purposes than food or natural resources. A single algorithm can be used in multiple industries, and given that the world doesn't develop evenly as a whole, there will be software opportunities in the real world (machinery), in processing the real world (commerce), in the virtual world (media), and in processing the virtual world (analytics), and these opportunities will increasingly require more and more knowledge and creativity.
- tedsanders 13y ago
  What's dishonest? I don't think I follow. Do you mean that housekeeper and radiologist were cherrypicked and that in reality laborers are at higher risk of automation than knowledge workers?
  - imsky 13y ago
    No, this part: "A common misconception about automation is the idea that it will primarily impact >low paying< jobs that require few skills or training. To illustrate that this is not necessarily the case, consider two very different occupations: a radiologist and a housekeeper." A hotelier's job, the well-compensated version of a housekeeper's job, is also difficult to automate. On the flip side, a good deal of information processing jobs, no matter how well compensated, can be automated. I think the point was made rather bluntly, without elaboration.
    - nrivadeneira 13y ago
      The point was made just fine. He said that there is not one definitive compensation class that will be primarily affected. It doesn't seem like you've refuted that.
    - 13y ago

angersock 13y ago

As much as I'd like to agree with the author, the case stated is pretty holey. To pick on the "We'll never be automated example": It's not that one day programs will write programs that write--oh wait, that's already happened. It's not that tools will come around that making throwing up a simple website with ecommerce functionality ea--shit, that happened too. It's that the core functions of software, from a business perspective, are pretty much nailed down now. It's that the average dudebro with an MBA and half a brain can throw together an MVP and start getting market feedback. It's that the homeless guy who lives down the street from me can publish an ebook from his acer. The thing that we all love so much, the removal of gatekeepers and democratization of information capital? Yeah, so, that thing is what will put us out of jobs. And that's fine. The thing the author misses is not that there won't be a few gigs around for people who need to optimize their database backends and red-black tree all the things and skiplist their twitters--it's that the vast majority of things that used to require people to find a coder to help them are now a few buttons away. Oh, and also that we've cultivated a user base so ignorant and attracted to simple glossy black boxes that they can't appreciate what it is to have a real engineer along for the ride anyways, nor how to usefully communicate with them if they had one. That's going to sting too.

imsky 13y ago
We do have programs that write programs. Who's using them? I like your optimism, but the average guy with an MBA definitely can't throw a MVP together, especially not in 2013 when the low hanging fruit have been steadily picked off. The bar is continuously being raised, and it'll be cheaper for the MBA to hire a developer to throw that MVP together, using highly complex and abstract components. If I'm getting the second half of your reply right, you're saying it's the availability of high-quality low-complexity zero-cost solutions to mundane problems that's going to put software developers out of a job. But that's exactly what I address in my post - these things were going to be automated anyway. And don't be disappointed by a user base attracted to glossy boxes - some of them will get curious eventually.
- timr 13y ago
  "We do have programs that write programs. Who's using them?" If you count things like Weebly, the answer is: a "whole bunch of people", heading rapidly toward "everyone". Not that long ago, every Weebly customer would have meant a programming job for someone. That kind of work is gone. 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. "the average guy with an MBA definitely can't throw a MVP together" You're wrong. It happens all the time. It happens so often that's a cliche. You can't go to a meetup in the valley without being assaulted by ten brohans looking for "feedback" on their "MVP". The important thing to realize is that the need for software engineers doesn't scale with the maximum complexity of software projects; it scales as a function of the average complexity: think of a bell curve, where the X-axis is "complexity", and "need for engineers" is the area under the curve to one side of some vertical line. We keep moving that line further and further toward greater complexity. So far, the distribution has shifted to keep up, but there's no guarantee that will keep happening. Are we going to need people to write complex, novel software in 2050? Absolutely. Will we need more people than we need to write complex, novel software today? That's not a question with a predictable answer. It might well turn out that the "average" programmer (say, the ones who know how to use Rails and jQuery and are fond of complaining about interview questions involving algorithms) is a doomed creature.

melbourne_mat 13y ago

It's a pretty complacent article. How long until software development has good quality automation - of a kind that drastically reduces the number of jobs? I suggest it's not as far away as the author thinks.

imsky 13y ago
We've had the tools to automate software development for years and there's been almost no movement in that direction.
dreamfactory 13y ago
Software generation is automated but when people are talking about software development they mean (technical) design. Design isn't a commodity or product but a one-off process and therefore by definition cannot be automated. The underlying topic isn't about automation of software development - it's about buy vs build, and as ever that depends on specific requirements and circumstances.
wvenable 13y ago
That's the wrong question. The very nature of software is automate jobs including software jobs and has since the very beginning. A programmer today is easily one or more orders of magnitude more productive as a programmer 20 years ago. We're all producing much more software with fewer people. The question is when will the demand for software be low enough that this ongoing process will reduce the number of programmer jobs.

jimbokun 13y ago

I feel like neither the article, nor any of the comments here so far, mention a very obvious point. The automation of tasks that formerly required writing software, are automated by someone writing new software. This should be the normal, everyday experience of the software developer. Take the software you wrote yesterday, and write higher level software on top of it today to accomplish things you couldn't before. So automating the software jobs of yesterday out of existence will require the software jobs of tomorrow. As for the computers writing their own software, that strikes me as indicating the Singularity has arrived, in which case all human jobs will be obsolete.

imsky 13y ago
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.
- eru 13y ago
  > 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.
  - imsky 13y ago
    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).
dmourati 13y ago
>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.

nrivadeneira 13y ago

Regardless of which article is correct (this one or the one it is referencing) in predicting the future of software employment, I think we'd all do well to keep an eye out for the future and be agile and ready enough if a Detroit-like situation does arrive. It should never be taken as a given that we'll always be highly sought after and well paid. With that in mind, I find Baugue's article much more useful considering I've never thought of an article that can be reduced to "Things are great, I don't think anything will change." to be of much help.

imsky 13y ago
That's a gross oversimplification of what I wrote. If you take only Baugues's conclusion ("don't be reckless, save and network, things may not always be so great") and ignore his premises, you're reducing the article to a platitude. My intent was to show how fears of automation are nothing new and should not stop developers from pursuing their careers.

clarky07 13y ago

Interesting that one of his examples, Wordpress, has contributed to lots of software jobs as well. Writing themes, plugins, etc can be fairly lucrative and probably more interesting than making a blog from scratch over and over. The whole point of writing software is to make it so you don't have to keep doing the same thing over and over. That doesn't mean there aren't new things to do. Software really is eating the world. If we run out of software jobs, it's probably because we've automated literally everything else already.

imsky 13y ago
That's a good point - there can be serious career opportunities in managing, supporting, and modifying ostensibly "automated" solutions. The core may be automated, but the ecosystem doesn't have to be.

Spooky23 13y ago

Software people are so arrogant. Auto workers arent and weren't unskilled manual labor.

michaelochurch 13y ago

There is something that can slaughter the job security of software engineers, but it's not technological advancement. Before I get to that, my personal forecast is: income expectancy for intelligent and hardworking people will continue to increase but so will variance. Eventually, the variance will become intolerable enough (sans regularization) that basic income will appear to be the only solution; even the smartest people will see a personal need for something like it. There will be a lot of struggling and fighting over implementation (e.g. do college graduates get more? how about families? should society incentivize or penalize reproduction?) but everyone will agree that it's necessary. That's probably about 30-50 years from now. Okay, so what's the #1 threat to software developers' job security? Not robots. We have robots that write code (compilers) and our jobs are still challenging. Instead, it's upper-level complacency in society. An elite that would rather hold position and keep relative rank than grow society and gain absolute prosperity (but at a lesser rate than others, losing rank). Historically, this is the norm for elites. Many people, especially in positions of power (because power selects such people) would rather reign in hell than serve in heaven. If they can conspire toward self-protection and social mediocrity, they will. The good news is that, in a large and heterogeneous society, it's actually very hard to hold any conspiracy together for very long. This is why conspiracy theories overstate the power of such organizations; conspiracies (lower-case 'c') exist all over the place (e.g. Davos assholes) but none have the power to run the world unilaterally. It's too chaotic and large. Societies and nations have set themselves back centuries when their elites conspired toward mediocrity, but I don't think the world elite is capable of doing so-- especially not now. If the global business elite figures out a way to conspire toward mediocrity, the people like us are fucked, because excellence will cease to matter and being good at what one does will just get one the reputation of a troublemaker. However, the likelihood that anyone could pull this together in a world with unprecedented distribution of technical literacy is incredibly low. As long as there are people looking to do things in this world, and the world continues to advance technologically, there will be a high level of demand for people who are technically competent. We might be applying our skills differently and changing industries, but there will be work for us, and society would have to reach an advanced (that is, certainly plausible but unlikely) state of degradation for us not to do that work on at least half-decent (e.g. middle-class) terms.

13y ago

wildgift 13y ago

Autowork in the 1930s and beyond may have been semi-skilled, but before widespread automation, it was a craft, and cars were expensive. This de-skilling has always been happening in software. Back in the 80s, word processors were written in assembly. Today, they can be written in JavaScript.

wildgift 13y ago

Aren't programmers more like the engineers who made the cars? Their work product is not just the design but the assembly line and the process, and those things help produce parts and cars. The autoworkers are more analogous to the people who work within software-controlled workplaces. That would be the people who pack boxes at Amazon.com, or do data entry, or customer support.

kamaal 13y ago

It will be too arrogant on our part to think we can't be automated. If you have used eclipse over the years you will see the kind of gradual automation happening there. Its not the kind of automation that produces code automagically all alone by itself. But software like eclipse pulls the barrier to entry too low to a point even people who understand nothing much about Java or in general about software can comfortable contribute to make a living out of it. And eclipse is only getting better with time. These days you can pretty much code complex Java application without even reading a book. I guess very soon, software like eclipse will fill-in-code-blocks as we express a intention. And then our job will be to stitch those blocks. This is what is dangerous. And this kind of thing has the potential to drive the supply up very quickly. Thereby the wages decline. There is no 1-1 mapping, between a automaker and programmer. But the theme is very common. I am even damn sure we will soon make software a commodity to a point when people can think in terms of abstract software blocks. Just like how a common man can today think of a car in terms of engine, clutch, gear etc.

rimantas 13y ago
> If you have used eclipse over the years you will see the > kind of gradual automation happening there The programmers job is not to do the things that eclipse can do. It's doing the things that he could do on paper, or just in his mind. Automating programming is like automating composers, writers and actors. Possible, but hardly desireable.

mseebach 13y ago

Both articles misses the mark. There are still autoworkers out there, just not in Detroit (OK, there are less of them, but they're still there). Autoworking didn't fail, Detroit (ie "big auto") failed. And they failed because they spend all their energy building moats (trade policy, emissions policy, unions etc) rather than improving and innovating (like the asian auto companies excelled at and the european ones partly kept up with), so when the house of cards came down, it came down hard. As long as we (software engineers) don't sequester ourselves wholesale in a homogenous monolith but continuously keep up with innovation, we should be well equipped to respond to changes in the market in time. The first article touches on this in the last paragraph, but I'm not convinced it's for the "right reasons".

ams6110 13y ago
The rote, unskilled work in auto assembly was easily automated (apply a spot weld here, insert a part there) but a lot of the skilled work was as well. The precision parts in automobiles used to be made by hand by machinists. This was highly skilled work, and it's now almost entirely been replaced by CNC. Machinists today, to the extent they still exist, are much more like programmers. They are still used for small and one-off jobs, but mass production of machined parts is programmed directly from the designs now, so you don't need a machinist in the picture at all for that. No amount of keeping up with innovation would have helped there.
- mseebach 13y ago
  If those people were let go (or retrained) continuously as they became redundant, instead of being employed in a unsustainable behemoth which then collapses all at once, they are much better positioned to re-qualify and re-join the workforce (maybe in the same, maybe in a different company) in a higher-skilled position. This could happen multiple times over a career.