Amazon Is Hiring Fewer Workers This Holiday Season, a Sign That Robots Are Replacing Them (qz.com)
Amazon is hiring around 100,000 additional employees this holiday season, which is fewer than the company added in either the 2016 or 2017 holiday seasons, when it brought in 120,000 additional workers. "Citi analyst Mark May says he thinks the reduction in seasonal hiring is strong evidence that Amazon is succeeding with plans to automate operations in its warehouses," reports Quartz. From the report: "We've seen an acceleration in the use of robots within their fulfillment centers, and that has corresponded with fewer and fewer workers that they're hiring around the holidays," May told CNBC. He added that 2018 is the "first time on record" Amazon plans to hire fewer holiday workers than it did the previous year. "Since the last holiday season, we've focused on more ongoing full-time hiring in our fulfillment centers and other facilities," Amazon spokesperson Ashley Robinson said in an email, adding that the company has "created over 130,000 jobs" in the last year. "We are proud to have created over 130,000 new jobs in the last year alone."
Amazon bought robotics company Kiva Systems for $775 million in 2012, and began using its orange robots in warehouses in late 2014. By mid-2016, it had become clear just how big a difference those robots were making. The little orange guys could handle in 15 minutes the sorting, picking, packing, and shipping that used to take human workers an hour or more to complete. In June 2016, Deutsche Bank predicted Kiva automation could save Amazon nearly $2.5 billion (those savings dropped to $880 million after accounting for the costs of installing robots in every warehouse).
Amazon bought robotics company Kiva Systems for $775 million in 2012, and began using its orange robots in warehouses in late 2014. By mid-2016, it had become clear just how big a difference those robots were making. The little orange guys could handle in 15 minutes the sorting, picking, packing, and shipping that used to take human workers an hour or more to complete. In June 2016, Deutsche Bank predicted Kiva automation could save Amazon nearly $2.5 billion (those savings dropped to $880 million after accounting for the costs of installing robots in every warehouse).
Or programmers.
I do a lot of CRUD-centric applications (tracking, work-flow, reporting, management info systems). With a good stack I'm quite productive and spend more time on analysis than diddling with code. With bad stacks I spend way too much time diddlying with code, and more stacks seem to be like that these days, partly because the choice of JavaScript widgets available makes PHB's crave ever fancier eye-candy that makes for ever more fragile/leaky systems that need ever more people to fix.
If automation either takes over the grunt work or creates more logical standards with fewer parts, a good many programmers will be let go since fewer are needed for the same position. The analyst/coder hybrid will disappear or shrink, leaving just analysts. 2 analyst/coder hybrids can then be replaced by 1 analyst.
Admit it, there's a lot of redundancy, BS, & bloat in most our stacks/techniques that can be factored out yet still do the necessary job. AI may have less incentive to add or keep unnecessary bloat; bots aren't biased for job security like we are.
Sorry, but humans unconsciously make selections/recommendations that make themselves more "needed". It's seen in the medical field also. I cannot predict what future AI will look like, but there's a decent chance it won't have this same bias, and thus factor itself better. Genetic algorithms may "evolve" stacks to fit company conventions tightly based on existing applications, for example. Fewer humans would then be needed to program with it. Our current stack manager stuck us with bloating microservices even though we don't need them because he thought it was "cool". AI probably won't. He should be fired by bots.
Field info (DB schema) is often replicated all over typical stacks, for example. DRY Principle says I should only have to state field info in ONE place, not ten. There are tools that duplicate the field info into the parts of the stack, but duplication only simplifies creation of code, not maintenance.
(I've kicked around ways to factor such, but most code tools are too file-centric or too hierarchical. Files are obsolete, I believe. Better code repositories would look more like RDBMS's so that we can use set theory on field info, UI layout, and event code instead of hierarchies. Set theory is more powerful than hierarchies and OOP inheritance. The future will eventually take us there, I believe. We are doing it wrong; stuck in the "tree past" out of habit. The Sets are coming. AI may discover this fact and our existing tools will dumped into landfill to be ridiculed the way we ridicule vinyl records and the ET cartridges. Field info/changes can then be entered into one place, and Boom! done. Go home and have sex and don't come back to work: a Set bot is in your chair now.)
Table-ized A.I.