What stops the tech industry from organizing? Thanks to decades of societal fawning over programmers and computer scientists, it is tempting now to turn to them to provide an answer. Those brainy boys will surely know! I suspect, however, that they do not. The chained labor process of technology production is much broader than programmers see from their interactive developer interfaces. So, we should treat their claims with comradely suspicion.

For example, in his Cosmonaut account of the large-language model bubble, Gary Levi suggests that tech workers’ entrenched craft pride in technology production will combat future capitalist cycles of exploitation. Since this claim is the extended subject of this article, it is worth quoting at length:

Most tech workers want to build things that matter, and that will stick around. We take pride in our work. We want to think in years, not sprint cycles. But that runs up against how capitalist markets operate… One aspect of our organizing should be that we, the workers, care more about building things correctly–in ways that are maintainable, stable, and useful to humans–than our bosses, structurally, ever can. It is not simply that we are in a struggle over our wages and conditions, but that our class position is such that we want to build things that are worthwhile and durable, and their class position is such that they, often, do not.^[1]

In this quote, Levi divides tech workers and management specifically over issues of quality in production. He is correct that this is a common feature of technical professionals, e.g., engineers and their codes of ethics, and he is correct to apply that description to programmers (the referent is given away by the term “sprint cycle”). He is incorrect, however, that the majority of tech workers would recognize themselves in his description. According to 2023 data from the US Bureau of Labor Statistics, “software and web developers, programmers, and testers” made up only 27.4% of the computer systems design industry and even then just around 55% of the “computer occupations” in that industry. Since Levi’s assumption is that tech work is centered around the skill and expertise held by a fraction of the actual workforce his organizing advice is invalid for most tech workers, and specifically those fractions most in need of workplace protections—the vast unrecognized majority, of content moderators, Amazon Mechanical Turkers, QA testers, and the like. Those are the workers that produce and validate the vast quantities of commodified data that social media platforms, ad brokers, and machine-learning algorithms depend on.

I say all this not to scrutinize a comrade’s choice of examples or to tally up correctives in framing. In the conduct of this critique, I have struggled to juggle all of the requisite parts. Some of the work of translation—from the language of the critiqued to the critic’s—is the duty of successful criticism. In this case, however, I think the difficulties I have faced in categorizing and responding to the comrade’s propositions is the product of a problem. I suspect part of it is the location Levi is writing from: within and around the US software production industry, as a programmer or computer science student. While their diagnoses have stable elements, their combination produces a confusion about the field they are meant to describe. For organizers, confusion like that is disabling. I will first unpack the conceptual errors contained in comrade Levi’s conclusion before moving to a recent socialist article on computation as a commodity to describe the ideological apparatus that makes it difficult for programmers to recognize those conditions.

The Cracked Foundation of a Labor Aristocracy

Levi’s claim about tech craft comes in a section he titles “The Nature of Tech Work,” which begins with a short division between production for goods and for the means of production itself:

Some tech work falls into the latter—for example, workers building and maintaining data centers and their network equipment, laying cable or manufacturing chips. Some fall into the former—for example, site reliability engineers maintaining user-facing applications—‘producing’ so to speak the social media feeds we consume.

In this division, Levi credits electrical engineers, electricians, chip manufacture, and software engineers with tasks of tech production. His emphasis for productive work is hardware and infrastructure, but in the analysis, he comes down hard on other tech workers:

But a lot of tech work isn’t in direct production at all. Rather it is supplementary to these classifications, effectively in research and development. Producing the ability to produce new types of goods, or produce more efficiently. This includes not just what we think of as R&D, but even mundane tasks like fixing bugs, implementing new dropdown menus, A/B testing form layouts–anything that does not just reproduce or deliver the product, but somehow changes it… But this job is never really necessary for day-to-day profit.

On the face of it, Levi has set up a difficult dilemma for tech workers—if their work is truly non-productive, it’s hard to imagine where computational craft labor would have much standing to re-impose its standards on production. If Levi’s argument holds, his call for craft values can’t have power behind it. Loss of software developers would be unthreatening to the capitalist.

But I don’t even believe Levi’s division above, for several reasons: he misdiagnoses programming labor as non-productive; and, by ignoring wider classifications of tech work, he over-generalizes his claims. For the first, I will keep my scope of critique narrowly on the tasks of the software engineer and programmer. Levi tries to imagine the programmer as akin to an academic, in producing long-term necessary but short-term inapplicable “R&D.” This is, if you think about the process of programming for even a moment, false. What Levi talks down as “mundane tasks” are essential components of programmers’ labor. As anyone who has ever written a script knows, fixing bugs—let alone exploits or vulns—is essential for producing a stable product. If a bug of a significant enough size is not patched, there is no product and, therefore, no production. Take a country, make it dependent on this kind of technical labor for several decades, and you have an industry that is capable of crippling entire sectors of the economy including flights, hospitals, and financial transactions for uninterrupted days at a time, as the CrowdStrike software update last summer proved.

The devaluing of labor that Levi does here is part of a trend. Programming, in its initial social forms, was not a valued profession—it began as “feminized clerical labor” performed by operators that coded male mathematicians’ and engineers’ models into the machines.^[2] It became clear after World War II, however, the social prestige that began to accumulate around the work and biases in corporate hiring converted software development into a male profession. As historian Nathan Ensmenger describes in his excellent history, the following generations of “computer boys” were able to construct a very successful model of unhegemonic masculinity for themselves. (In the United States, we are, of course, all suffering greatly under the consequences of that model today.)

On the one hand, programmers found themselves subordinated to management (in ways that made management profoundly uncomfortable) and conducting enormous quantities of menial maintenance labor. On the other, they were able to carve out and justify domains for themselves in the corporate structure. They did this by layering a mythology of craft labor onto their occupation through sensationalized industry guides like Frederick Brooks’ The Mythical Man-Month. Ensmenger explains the strategy:

By characterizing the work that they did as artistic, programmers could lay claim to the autonomy and authority that came with being an artist. If it were true, as one industry observer suggested in the late 1960s, that ‘generating software is 'brain business,' often agonizingly difficult intellectual effort,’ then talented programmers were effectively irreplaceable, and should be treated and compensated accordingly. On the other hand, being artistic might also imply that one was not scientific or professional.^[3]

And the ideological project of programming as craft labor has continued well into the present day, through books like Eric Raymond’s The Cathedral and the Bazaar and the broader free/open-source programming movement.

We can recognize the two-step that comrade Levi makes about tech work in the above narrative. The simultaneous elevation and denigration of programming labor, however, poses a problem. It is hard to imagine software engineers and programmers mustering the trade, if not class, consciousness required to meet this moment. Throughout the 20th century, programmers failed both to unionize and to professionalize (in the sense of maintaining control over entrance into their profession and securing a social mandate for a monopoly over their kind of labor). The idea also ignores the reality that the occupation is currently under threat of both automation and deskilling—through the tools that programmers themselves made. The hollowing of dedication to craft has even reached the computer scientists, who confine their research questions to only the most managerial of concerns: can it be done, and how fast?

The second quibble I have with Levi’s division is that it obscures the majority of tech workers. The United States stands on a global division of labor, all of which could be considered “tech.” The artisanal imaginaries I described before are now used to normalize the US as the beneficiary of this system. Within the US and abroad, data workers moderate content, test user interfaces, and produce the many minute human tasks that computers have as yet been unable to automate. They produce the data that allows for algorithmic products to proliferate into new markets and capture new customers. They make pittance wages through piecework that can, especially for content moderators, leave them with permanent psychological trauma. Those workers have very different ideas of craft than Levi. They are the tech industry’s equivalent of Amazon warehouse workers and for the labor movement to overlook them is folly.

Mystification and the Commodities of Computation

As I mentioned, I do not raise these points because I think they are errors of framing or analysis, but a product of consistent errors that computer programmers and “scientists” make in studying their labor. In a similar vein to Levi, Sam Heft-Luthy of the DSA Red Star caucus recently proposed an analysis of compute—a shorthand for referring to computation as a certain amount of work, akin to horsepower—as a commodity.^[4] Heft-Luthy correctly identifies that computers mystify the immense labor embedded within them and then elaborates several technical methods of abstraction that enable that mystification—programming subroutines, application programming interfaces, and large-language models (commonly misidentified as “artificial intelligence”). He takes on the sacred cow of the computational classes, the free software movement:

As long as capitalism organizes production on a global scale, utopian projects for software development will remain ephemeral. The commodity form and its associated concepts of abstraction in computation are a powerful scaling technology that have demonstrated the ability to outcompete these isolated projects.

I study the history and culture of computation and, reading Heft-Luthy’s proposal, the disconnection between his examples gnawed at me. Computers do have ties to workshop production methods, but academics at Cambridge did not produce that connection through the subroutine, a means of dividing computational tasks into smaller units. Scarcity of access to expensive compute meant that timesharing practices in lab spaces developed alongside the technology itself—armies of machine operators punching cards that encoded the commands for early computers.

The free software movement has become a source of free labor for capitalist developers, but that itself was a political project. Programmers forced to work at odd hours and in restricted areas with computers have long used those odd hours to tinker with their craft. Free software projects provided infrastructural foundations for most of the computers and Internet we use today. “Open source” became a popular term partially to make the idea of non-proprietary code palatable to companies.^[5] We can see the developed forms of this exploitation in company crowdsourcing projects, hackathons, and red-teaming exercises that source free quality testing, design and development, and software production labor from participants.^[6] (This is another reason that Levi’s reclamation of craft values is a nonstarter: many of the software infrastructures we depend upon, e.g., Linux, were free labor performed for the love of craft that did not ensure circuits of capital flow uninterrupted.^[7])

How are the programmers so confused about the social context of their labor? First, venture capitalists and tech executives, with the assistance of programmers, have exalted the physical form of the computer into apotheosis. In his history, Ensmenger discusses how perpetual anxieties over the supply of computational labor shaped academic fields and job training programs—for a long time, we have simply had no idea what made for a good programmer. This emphasized, on the one hand, looking for aptitude in logic games and puzzles (reflecting computation’s mathematical and philosophical influences) and, on the other, physical proximity to hardware.

This latter approach also developed into the educational philosophy of “constructivism” evangelized by Nicholas Negroponte and the MIT Media Lab, which emphasized students spending as much time with computers as possible and dismissed the value of teaching labor in the process. Sociologist Morgan Ames, in her study of the dismal results of Negroponte’s One Laptop Per Child program, argues that physical computers should be seen as “charismatic technology,” in a Weberian sense:

[A] charismatic technology derives its power experientially and symbolically through the possibility or promise of action: what is important is not what the object is but how it invokes the imagination through what it promises to do. The material form of a charismatic technology may be part of this but is less important than a technology’s ideological commitments—its ‘charismatic promises.’ This means that a charismatic technology does not even need to be present or possessed to have effects.^[8]

Roughly, hardware is a charismatic technology, while software often is not. We cannot confuse the means of production with the commodity. Software, with its endless maintenance, is inglorious; attention slips off of it. It needs continuous labor to stabilize it as a commodity that the marketplace can recognize. But that doesn’t mean it isn’t an important part of production.

Closing the Loop

So, I agree with Heft-Luthy that computation is fetishized, but I would make a stronger claim than him. It is not just that we need to remember certain details of material production for computers. Insisting on a materialist take on the computer too easily ignores that the entire way we socially produce knowledge about computers leads to their mystification.^[9] Sober suspicion of unexamined hype, of unthinking fealty to charismatic technologies, and of the praise of technical labor are all required for a materialist analysis of the tech industry. For programmers and software engineers, they need to beware the ideology that their field and socialization steeps them in if they want to have any hope of organizing their workplaces.

To remedy this problem,^[10] tech workers need to perform more inquiry into their workplaces and the sites of labor they are connected to. There needs to be a uniform sense of what its labor problems are and what types of labor need to organize to address them. By design, however, computational labor is collaborative and spatially or temporally distributed. Workers collaborate in production across continents and generations in a way that is difficult to perceive and alter. This is an integral part of capitalist organization of technical labor that obscures labor relations.

I have written this article with an academic style, but that is just because that is the way I know computers. I normally love learning about an industry from the perspective of workers within it. Personal observation is one way to short circuit capitalist ideology. But the US computational classes are a special case. I am, as someone who has also done menial data work under precarious conditions, exhausted by watching programmers and software engineers be placed on a pedestal over and over again. This is not to say that programmers and software engineers should only organize in solidarity or around other workers’ issues, but that they need to understand their own workplace and its connection to others’ labor.

Now, as a social scientist, let me say: proximity to computers does not translate in any way to the social knowledge we need to organize. For the programmers, conduct inquiry, read, learn where your data and compute come from and, therefore, who you need to stand in solidarity with. Marx called for a critical history of technology, and that knowledge is particularly important for technical workers. Some of this work has certainly been done already in, for example, the Notes from Below issue on tech work and in CODE-CWA’s reading list for organizers. Interested readers should also look to the sources I’ve cited here, as well as Jathan Sadowski’s newly published The Mechanic and the Luddite: A Ruthless Criticism of Technology and Capitalism, which provides an up-to-date Marxist analysis of ideology and the process of exploitation in the tech industry.

Look askance at people who claim to understand the political economy of computers just because they code. These boxes of blood, overflowing with acid-etched wafers, that we use to read and work are not our saviors; they are shackles. If we had the strength, the courage, and the ability (we do not), we would stand as one and break these machines like we did the looms of old. Or put them to work in service of a new world.

1. Gary Levi, “Circuit Breakers: Profit, Bubbles, Crisis, and Chokepoints in the Tech Economy,” Cosmonaut Magazine, January 15, 2025, https://cosmonautmag.com/2025/01/circuit-breakers-profit-bubbles-crisis-and-chokepoints-in-the-tech-economy/.

   ↩

2. Jennifer S. Light, “When Computers Were Women,” Technology and Culture 40, no. 3 (1999): 455–83.

   ↩

3. Nathan Ensmenger, The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise (History of Computing; MIT Press, 2010).

   ↩

4. Sam Heft-Luthy, “On the Commodity Fetish of Computation,” Socialist Forum, Fall 2024, https://socialistforum.dsausa.org/issues/fall-2024/on-the-commodity-fetish-of-computation/.

   ↩

5. Gabriella E. Coleman, Coding Freedom: The Ethics and Aesthetics of Hacking (Princeton University Press, 2013).

   ↩

6. Lilly Irani, “Hackathons and the Making of Entrepreneurial Citizenship,” Science, Technology, & Human Values 40, no. 5 (2015): 799–824. https://doi.org/10.1177/0162243915578486.

   ↩

7. Tiziana Terranova, “Free Labor: Producing Culture for the Digital Economy,” Social Text 18, no. 2 (2000): 33–58.

   ↩

8. Morgan G. Ames, The Charisma Machine: The Life, Death, and Legacy of One Laptop Per Child (Infrastructures; MIT Press, 2019)

   ↩

9. For an example of this process developing over the past few years, with AI ethics, see: Ahmed, Shazeda, Klaudia Jaźwińska, Archana Ahlawat, Amy Winecoff, and Mona Wang, “Field-Building and the Epistemic Culture of AI Safety,” First Monday, April 2024, https://doi.org/10.5210/fm.v29i4.13626.

   ↩

10. Aside from improving the devastated US education system, I have only the following unhelpful request: Please, comrades, read more. And I will accept a crown of pedantry in return.

    ↩