Does AI Make Programming Feel Like Factory Work?
(This blog post is derived from this video on my YouTube channel.)
The New York Times recently published an article about programmers at Amazon complaining that their jobs were beginning to look like warehouse work because of AI.
At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work Pushed to use artificial intelligence, software developers at the e-commerce giant say they must work faster and have less time to think. Others welcome the shift.
Their managers are turning the screws on them, saying they should be using AI to get more done in less and less time.
Three Amazon engineers said that managers had increasingly pushed them to use A.I. in their work over the past year. The engineers said that the company had raised output goals and had become less forgiving about deadlines.
This is where the comparison with blue-collar warehouse workers comes in. These programmers are now saying that they feel like “bystanders in their own jobs”.
The automation of coding has special resonance for Amazon engineers, who have watched their blue-collar counterparts undergo a similar transition.
They’re making the same argument that factory and warehouse workers have been making for a long time: their jobs have been stripped of all creativity and craft, becoming mechanized, repetitive, and soul-crushing.
The new approach to coding at many companies has, in effect, eliminated much of the time the developer spends reflecting on his or her work. “It used to be that you had a lot of slack because you were doing a complicated project — it would maybe take a month, maybe take two months, and no one could monitor it,” Dr. Katz said. “Now, you have the whole thing monitored, and it can be done quickly.”
“White-collar" programmers are now feeling the same pressures that have been felt in mechanical factory work since the dawn of the industrial age.
I want to tie these recent developments back to some very old ideas that go back to the very birth of the field of software engineering itself—and hopefully shed light on some common themes that have been recurring in our field since the very beginning.
Blue-collar coders
Back in 2013, I wrote a blog post reacting to some prominent bloggers talking about “blue-collar coders.” They were arguing that the work of web and software development can and should be thought of as blue-collar work.
Here is Anil Dash writing back in 2012 – he is making the case for software engineering to be treated as vocational education. “We need web dev vo-tech”.
High schools have long offered vocational education, preparing graduates for practical careers by making them proficient in valuable technical skill sets which they can put to use directly in the job market right after graduation. Vocational-technical schools (vo-tech) provide trained workers in important fields such as healthcare, construction trades, and core business functions like accounting. For a significant number of my high school peers, vo-tech was the best path to a professional job that would pay well over the duration of an entire career.
Now it’s time that vo-tech programs broadly add internet and web technologies to the mix. We need web dev vo-tech.
And here is Laurie Voss making a similar argument about how knowledge workers should think of themselves more as blue-collar workers. He makes the crucial comparison to factory work and Taylorism. Voss argues for that same model to be applied to web development.
Think about how a physical factory worked. The reason unskilled jobs in manufacturing, say, cars existed is because some very highly skilled people first got together and looked at the process of building a car and said “okay, we can automate this bit and this bit and this bit, but making machines to do this bit is way too hard”. The blue collar workers of Detroit didn’t know how to build cars; they knew how to operate one particular bit of machinery. The only people who knew how to build cars were the guys who put the machines together.
Now let’s try applying that model to web development, an example I pick because I know a fair bit about building web sites. Think about all the businesses in the world that have web sites, or need them built or maintained. There is an entire industry built around cranking out simple websites for small businesses, in WordPress or Drupal or a thousand proprietary solutions. This industry is making a bunch of smart freelancers a ton of cash, which is great for them individually, but terrible for the tech sector as a whole.
This is an argument that can be applied to any technology that’s fairly mature, where the methods for achieving a certain outcome or building a certain product are well-understood. It’s not surprising that even back in 2012, when web development was already mature with a fairly well-understood stack, he would make an argument like this.
My old blog post reacting to these two was making the opposite case. I argued that it’s not tenable to think of software development purely as a vocational line of work, simply because of the pace at which technology changes.
The problem with this vocational tech approach is that it implicitly assumes the knowledge gained during vocational training will be relevant for a long period of time. The pace of technology change renders that unviable.
But the core philosophy that all these people are talking about is Taylorism. And Taylorism is also deeply linked to the birth of software engineering. In another very old blog post I reflected on Taylorism and how it relates to programming. Taylorism is a deep topic, but if you were to drastically simplify it, its core ideas are these two: you measure everything, and you separate thinking from doing.
Briefly, Taylorism has two central tenets:
- Measurement: associate metrics with all aspects of work.
- The separation of thinking and doing: An educated class of managers measures and plans all the work, and is responsible for the overall process, while a class of laborers carries out the implementation of those plans.
This is exactly the point Voss was making when comparing software development to what happens in a car factory. Someone thinks about, examines, and codifies a process (the thinking part), and they then bring in an army of laborers to do tiny bits of that process (the doing part).
The birth of software engineering
Where this links up to software engineering is that back in 1968, the very term “software engineering” was coined at a NATO conference of the top people building computers and writing software at the time. One of the central themes the attendees were discussing was the notion of industrializing the process of building software. Doug McIlroy expressed this by saying, “The software industry is not industrialized,” and compared it to the mass production techniques used in physical factories.
Software production today appears in the scale of industrialization somewhere below the more backward construction industries. I think its proper place is considerably higher, and would like to investigate the prospects for mass-production techniques in software.
He was calling for a catalog of interchangeable parts with well-understood characteristics, and for applying the same methods used for physical assembly in factories to the creation of software.
The idea of subassemblies carries over directly and is well exploited. The idea of interchangeable parts corresponds roughly to our term
modularity, and is fitfully respected. The idea of machine tools has an analogue in assembly programs and compilers. Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. There do not exist manufacturers of standard parts, much less catalogues of standard parts. One may not order parts to individual specifications of size, ruggedness, speed, capacity, precision or character set.
Another lens through which you can view this entire argument is what I call the notion of operation versus expression. The key idea is that sometimes you’re operating a piece of machinery, and the goal is to quickly achieve some well-defined end. But other times, you’re trying to express yourself, which goes back to the notion of looking at what you’re doing as a craft.
Software engineers like to talk about how they craft their software. Are you operating a piece of machinery, or are you trying to express yourself and create something? This argument comes up again and again in the software industry whenever there’s a big shift in how we build software. Even when IDEs were becoming popular, the idea that they were taking the craft away from software engineering was widely expressed. Many software engineers felt that IDEs were constraining the creative ways in which they could write software.
This argument is now, of course, coming up again because AI is once again fundamentally changing the way we write software. But the point of this whole rant is that going back to the very birth of the field of software engineering, we’ve wanted to make it industrial. We’ve wanted to make it Taylorist. And there has been a steady stream of developments—from compilers and high-level languages to IDEs and now, finally, AI—that have made us steadily march in that direction.