7 ms·

Hold on a minute. You can't discuss labor markets without discussing productivity. In the heyday of the automotive industry, the best auto worker in the world

Hold on a minute. You can't discuss labor markets without discussing productivity. In the heyday of the automotive industry, the best auto worker in the world produced about the same output as the average auto worker. Maybe they messed up less, but being a genius autoworker didn't let you tower head and shoulders above the competition, because car factories are designed with auto workers as interchangeable parts. We've tried that with developers. If it had worked, all development would be outsourced to India and the Philippines by now, and developers would be forming unions to lobby for higher pay. The reality is that the market pays for productivity, in the long-run. Maybe having more junior developers coming out of bootcamps puts downward pressure on wages, but as long as development is a meritocracy where the best performers are much better than the worst performers, there's always going to be a premium on people that really know their stuff. Maybe one day we'll live in a world with lots and lots of really good devs. I don't mind living in that world as much, because I can control my fate to a far larger extent that someone who moved to Detriot in 1960 and was unfortunate enough to stake their whole life on a company pension and a single industry. EDIT: typo

mkr-hn 13y ago
I think the argument is that the skill level and number of people needed for most development jobs will be lowered with platforms and tools that make it easy for a minimally trained user to do it. Someone still has to make the tools and platforms, but implementing them won't take as many people. Think about how many wildly popular websites run with a handful of people. How long will it be before you don't even need more than a few people in a datacenter? Robots will eventually be able to change out dead drives on a RAID array and inspect the backup generator as well as a technician. People saying things like "everyone should be a developer" are coding the same people they're encouraging out of a potential career path. Which is fine, but the contradiction gets annoying.
- nohuck13 13y ago
  I think that's a key question, but I've never been a fan of the notion that robots (or efficient frameworks) are going to put us all out of jobs. If you look at what we've actually seen in the last 20 years, efficient frameworks enable entrepreneurship and wealth creation on a scale that wasn't possible in the past. Sure, there are fewer people employed doing nitty gritty stuff, but the size of the economic pie is far bigger than it once was, largely because of labor-saving technology and frameworks. If you want to argue that better frameworks will drive down wages, the argument to make is that better frameworks will reduce development time without facilitating wealth-creation. EDIT: maybe this will happen, I can't predict the future. Rereading your post, I guess this is more or less what you were saying. But then the question is, what's going to change to reduce growth?
  - ori_b 13y ago
    The argument is that the pie is already unevenly distributed. In the future, it will be even more unevenly distributed, and the skewing of the distribution will outpace the growth of the pie.
    - peterjancelis 13y ago
      No. Wealth will be more volatile. The smart will get richer.
      - ori_b 13y ago
        That doesn't contradict what I said. It may be concentrated among the smart, but it will still be concentrated.
        mkr-hn 13y ago
        More importantly, the people at the top need the people lower on the ladder to pay their salary, either through companies that advertise or by paying directly. There may be an implosion at the top if they automate too many jobs away before magic market forces create replacements.
- rjsw 13y ago
  You had toolmakers in the auto industry too.
- mbesto 13y ago
  People saying things like "everyone should be a developer" In a larger sense these people are simply saying "we need more skilled labor" Think about how many wildly popular websites run with a handful of people. And yet Google, Amazon, Groupon, etc can't always get sales or support done correctly without people. Very few companies are massive commercial successes without a large amounts of people. I can only think of a few off the top of my head, and they aren't the norm.
- SomeCallMeTim 13y ago
  >Think about how many wildly popular websites run with a handful of people. You're talking about the "Silver Bullet," [1] whether you mean to or not. There have been hundreds of attempts to reduce the complexity of development, starting in the '50s and continuing pretty much continually until today. And just as Fred Brooks describes in the book I linked, that kind of productivity increase doesn't happen in software. And won't happen in software. You do get ways of better managing complexity. Look at object-oriented programming, for example. That's a recent development, right? Sure, as long as you're old enough to consider the 1970s to be "recent." [2] Not me, thanks. ;) The best you do get is a single problem being solved in a somewhat general manner. The CMS gives us a generic web site/blog. Square and others give us easy commerce integration. And so on: Specific common problems solved really well. Yes, these are things that previously took many man-hours of time to create one-off versions of, but what happens is that people want more and more complex (and differentiated!) functionality in their web sites or apps. And that differentiation is by definition not able to be packaged in bulk. As soon as it gets interesting, I don't care how easy you've made the "language" that specifies it, you still need a programmer to implement it. Or someone who can think like one. And most people not only don't think like programmers, they firmly believe they can't think like programmers, and so refuse to even try to learn how. Or at the very least they have an image that programming is dull or dry or boring. There are still huge barriers to people entering programming en masse. And even if they did, it would be the lowest complexity jobs that would be harder to get -- the ones where the barrier to entry is really low. I work tasks a few tiers of complexity above those jobs; I'm not worried about being replaced by a new wave of college graduates any time soon. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet [2] https://en.wikipedia.org/wiki/Object-oriented_programming#History https://en.wikipedia.org/wiki/Object-oriented_programming#Hi...
- dclowd9901 13y ago
  And what's different is that auto workers weren't also building and designing the factories they worked in. Certainly there's something to be said for being the one who can design and build a tool vs being the one who can simply use it.
Demiurge 13y ago
And this also means that developers in this case are evolving, we are technologists. Which is more like the car designers. And these guys are still around and getting payed a lot, and probably will be for a long time, designing spaceships. Software engineering, which also requires original thought, also will never disappear. So I would say the original authors analogy is dead wrong.
- cellis 13y ago
  I'm sure CAD software made lots of car designers redundant. What most people in our industry seem to not realize is the intense power accumulation laws at work. 1 Designer can now do the work that 50 could in the 50s. All that wealth is now going to one person (or whoever captures the wealth they would otherwise generate -- in this case car co. shareholders and customers).
  - bluedino 13y ago
    Once the gas engines become obsolete and everyone's car runs on an electric motor, that's going to make a lot of designers hit the unemployment line. A gasoline engine has thousands and thousands of little parts and associated systems. Electric motors are very, very simple by comparison. Someone needs to design and manufacture all those little parts.
karlkatzke 13y ago
While that's true for the autoworker example, it's not true for the lawyer example: The best lawyers produced much more than the normal lawyers. I would put programmers roughly on par with the law industry, not with the auto industry.
- grandalf 13y ago
  Please elaborate. Define "best" in the context of lawyers. Is it a graduate of Harvard Law? Or someone who managed to make partner at a major firm? How do you define output for a lawyer? Billable hours? Cases won? Contracts written?
  - derefr 13y ago
    The nice thing about measuring output for lawyers, is that a fair share of them work as either independent contractors, or partners. In both cases, you've got the best proxy for productivity we have: profit.
  - cowsandmilk 13y ago
    defining "best" for a lawyer is similar to defining "best" for a software developer. It is production of quality at a rapid rate, choosing the right tools for a job, etc.
    - fnordfnordfnord 13y ago
      Aren't you guys using the economic definition of 'best' as in best = brings_in_the_most_money_per_unit_of_time_expended
      - grandalf 13y ago
        They are. This would lead to the conclusion that Linus Torvalds is fairly middle of the road, etc.
        mseebach 13y ago
VLM 13y ago
I believe a more accurate analogy would be helpdesk/admins/sysadmins/support/cable pullers map to factory line workers vs software devs map to mechanical engineers Detroit has always had genius level engineers doing amazing stuff. Totally different issue if any of it is ever allowed out the labs into products, but ...
walshemj 13y ago
Well an production line's efficiency is defined by how well the line is engineered - the humans are effectively fleshy robots. Though there are/where a lot of "spanish practices" in traditional engineering.
cturner 13y ago
In the heyday of the automotive industry, the best auto worker in the world produced about the same output as the average auto worker Agree. Also, there's a strong trade union theme to the history of autoworkers which doesn't really map to the developer experience. Something related though - what about the toolsmiths who built the factory processes and machines? I'd guess that with those guys there'd have been a big gap in productivity, and there'd have been a strong collaboration/teamwork angle and theme of iteration. They would have been scarce - maybe they still are.
- nohuck13 13y ago
  I agree that parallel is really interesting. Its especially true with the classic Agile stuff, where a lot of the processes are explicitly borrowed from the automotive industry, particularly Toyota: Kanban (lean process management), kaizen (collective ownership as a means to reduce bugs/defects), the notion that it's better to fail fast and stop the line, rather than send a defective product to downstream processes.

mkr-hn 13y ago

I think the argument is that the skill level and number of people needed for most development jobs will be lowered with platforms and tools that make it easy for a minimally trained user to do it. Someone still has to make the tools and platforms, but implementing them won't take as many people. Think about how many wildly popular websites run with a handful of people. How long will it be before you don't even need more than a few people in a datacenter? Robots will eventually be able to change out dead drives on a RAID array and inspect the backup generator as well as a technician. People saying things like "everyone should be a developer" are coding the same people they're encouraging out of a potential career path. Which is fine, but the contradiction gets annoying.

nohuck13 13y ago
I think that's a key question, but I've never been a fan of the notion that robots (or efficient frameworks) are going to put us all out of jobs. If you look at what we've actually seen in the last 20 years, efficient frameworks enable entrepreneurship and wealth creation on a scale that wasn't possible in the past. Sure, there are fewer people employed doing nitty gritty stuff, but the size of the economic pie is far bigger than it once was, largely because of labor-saving technology and frameworks. If you want to argue that better frameworks will drive down wages, the argument to make is that better frameworks will reduce development time without facilitating wealth-creation. EDIT: maybe this will happen, I can't predict the future. Rereading your post, I guess this is more or less what you were saying. But then the question is, what's going to change to reduce growth?
- ori_b 13y ago
  The argument is that the pie is already unevenly distributed. In the future, it will be even more unevenly distributed, and the skewing of the distribution will outpace the growth of the pie.
  - peterjancelis 13y ago
    No. Wealth will be more volatile. The smart will get richer.
    - ori_b 13y ago
      That doesn't contradict what I said. It may be concentrated among the smart, but it will still be concentrated.
      - mkr-hn 13y ago
        More importantly, the people at the top need the people lower on the ladder to pay their salary, either through companies that advertise or by paying directly. There may be an implosion at the top if they automate too many jobs away before magic market forces create replacements.
rjsw 13y ago
You had toolmakers in the auto industry too.
mbesto 13y ago
People saying things like "everyone should be a developer" In a larger sense these people are simply saying "we need more skilled labor" Think about how many wildly popular websites run with a handful of people. And yet Google, Amazon, Groupon, etc can't always get sales or support done correctly without people. Very few companies are massive commercial successes without a large amounts of people. I can only think of a few off the top of my head, and they aren't the norm.
SomeCallMeTim 13y ago
>Think about how many wildly popular websites run with a handful of people. You're talking about the "Silver Bullet," [1] whether you mean to or not. There have been hundreds of attempts to reduce the complexity of development, starting in the '50s and continuing pretty much continually until today. And just as Fred Brooks describes in the book I linked, that kind of productivity increase doesn't happen in software. And won't happen in software. You do get ways of better managing complexity. Look at object-oriented programming, for example. That's a recent development, right? Sure, as long as you're old enough to consider the 1970s to be "recent." [2] Not me, thanks. ;) The best you do get is a single problem being solved in a somewhat general manner. The CMS gives us a generic web site/blog. Square and others give us easy commerce integration. And so on: Specific common problems solved really well. Yes, these are things that previously took many man-hours of time to create one-off versions of, but what happens is that people want more and more complex (and differentiated!) functionality in their web sites or apps. And that differentiation is by definition not able to be packaged in bulk. As soon as it gets interesting, I don't care how easy you've made the "language" that specifies it, you still need a programmer to implement it. Or someone who can think like one. And most people not only don't think like programmers, they firmly believe they can't think like programmers, and so refuse to even try to learn how. Or at the very least they have an image that programming is dull or dry or boring. There are still huge barriers to people entering programming en masse. And even if they did, it would be the lowest complexity jobs that would be harder to get -- the ones where the barrier to entry is really low. I work tasks a few tiers of complexity above those jobs; I'm not worried about being replaced by a new wave of college graduates any time soon. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet [2] https://en.wikipedia.org/wiki/Object-oriented_programming#History https://en.wikipedia.org/wiki/Object-oriented_programming#Hi...
dclowd9901 13y ago
And what's different is that auto workers weren't also building and designing the factories they worked in. Certainly there's something to be said for being the one who can design and build a tool vs being the one who can simply use it.

Demiurge 13y ago

And this also means that developers in this case are evolving, we are technologists. Which is more like the car designers. And these guys are still around and getting payed a lot, and probably will be for a long time, designing spaceships. Software engineering, which also requires original thought, also will never disappear. So I would say the original authors analogy is dead wrong.

cellis 13y ago
I'm sure CAD software made lots of car designers redundant. What most people in our industry seem to not realize is the intense power accumulation laws at work. 1 Designer can now do the work that 50 could in the 50s. All that wealth is now going to one person (or whoever captures the wealth they would otherwise generate -- in this case car co. shareholders and customers).
- bluedino 13y ago
  Once the gas engines become obsolete and everyone's car runs on an electric motor, that's going to make a lot of designers hit the unemployment line. A gasoline engine has thousands and thousands of little parts and associated systems. Electric motors are very, very simple by comparison. Someone needs to design and manufacture all those little parts.

karlkatzke 13y ago

While that's true for the autoworker example, it's not true for the lawyer example: The best lawyers produced much more than the normal lawyers. I would put programmers roughly on par with the law industry, not with the auto industry.

grandalf 13y ago
Please elaborate. Define "best" in the context of lawyers. Is it a graduate of Harvard Law? Or someone who managed to make partner at a major firm? How do you define output for a lawyer? Billable hours? Cases won? Contracts written?
- derefr 13y ago
  The nice thing about measuring output for lawyers, is that a fair share of them work as either independent contractors, or partners. In both cases, you've got the best proxy for productivity we have: profit.
- cowsandmilk 13y ago
  defining "best" for a lawyer is similar to defining "best" for a software developer. It is production of quality at a rapid rate, choosing the right tools for a job, etc.
  - fnordfnordfnord 13y ago
    Aren't you guys using the economic definition of 'best' as in best = brings_in_the_most_money_per_unit_of_time_expended
    - grandalf 13y ago
      They are. This would lead to the conclusion that Linus Torvalds is fairly middle of the road, etc.
      - mseebach 13y ago

VLM 13y ago

I believe a more accurate analogy would be helpdesk/admins/sysadmins/support/cable pullers map to factory line workers vs software devs map to mechanical engineers Detroit has always had genius level engineers doing amazing stuff. Totally different issue if any of it is ever allowed out the labs into products, but ...

walshemj 13y ago

Well an production line's efficiency is defined by how well the line is engineered - the humans are effectively fleshy robots. Though there are/where a lot of "spanish practices" in traditional engineering.

cturner 13y ago

In the heyday of the automotive industry, the best auto worker in the world produced about the same output as the average auto worker Agree. Also, there's a strong trade union theme to the history of autoworkers which doesn't really map to the developer experience. Something related though - what about the toolsmiths who built the factory processes and machines? I'd guess that with those guys there'd have been a big gap in productivity, and there'd have been a strong collaboration/teamwork angle and theme of iteration. They would have been scarce - maybe they still are.

nohuck13 13y ago
I agree that parallel is really interesting. Its especially true with the classic Agile stuff, where a lot of the processes are explicitly borrowed from the automotive industry, particularly Toyota: Kanban (lean process management), kaizen (collective ownership as a means to reduce bugs/defects), the notion that it's better to fail fast and stop the line, rather than send a defective product to downstream processes.