In 1962, at a RAND symposium on programming languages, Fred Gruenberger offered a weary observation to his colleagues:

You know, I’ve never seen a hot dog language come out yet in the last 14 years — beginning with Mrs. Hopper’s A-0 compiler . . . that didn’t have tied to it the claim in its brochure that this one will eliminate all programmers. The last one we got was just three days ago from General Electric (making the same claim for the G-WIZ compiler) that this one will eliminate programmers. Managers can now do their own programming; engineers can do their own programming, etc. As always, the claim seems to be made that programmers are not needed anymore.

Sixty-three years later, the brochure arrived again. In March of 2025 the CEO of Anthropic predicted that within three to six months AI would be writing ninety percent of all code. The industry’s vocabulary has since shifted from “assistants” to “agents”: software entities that can be handed a goal rather than an instruction, and that will plan, code, test, and debug on their own while a human “AI engineer” supervises a fleet of them from above.

I spent the better part of a decade writing a book about the people these agents are supposed to replace. The Computer Boys Take Over is a history of the recurring conviction, held by managers, manufacturers, and more than a few computer scientists, that programmers were a problem to be eliminated. What strikes me about the current moment is not how novel it is but how familiar.

The computer will program itself

The dream of eliminating the programmer is as old as the programmer. In the division of labor sketched out by Herman Goldstine and John von Neumann in the 1940s, the intellectual work of computing was done by a “planner,” who analyzed the problem and prepared a flowchart. The flowchart was then handed to a “coder,” whose job was simply to translate it into machine instructions. Planning was analytic and high-status; coding was clerical, mechanical, and, not coincidentally, largely assigned to women. An early draft of the UNIVAC programming manual put it plainly: the programmer “studies the problem, determines the appropriate method of solution, and prepares the flow chart,” while the coder “need only be familiar with the technique of reducing the flow chart to the specific instructions.”

The trouble was that coding turned out not to be mechanical. One could not turn a flowchart into working code without understanding the machine, the problem, and the many ways in which the two refused to cooperate. By the end of the 1950s programming was a “black art,” dependent on individual talent and craft knowledge, and its practitioners were in chronically short supply.

The manufacturers’ response was to automate the problem away. “Automatic programming systems,” the technology we would later simply call programming languages, promised to “eliminate the middleman” by letting users communicate with the computer directly. The computer would program itself. IBM’s original proposal for FORTRAN claimed it would “virtually eliminate programming and debugging”; John Backus believed a truly automatic language would let scientists and engineers dispense with “coders” entirely. COBOL was designed to be “Englishlike” so that its programs could be read, and in principle written, by managers; its appeal to executives, one contemporary observed, was that it might prevent “letting the ‘computer boys’ take over.”

Herbert Simon went further than anyone. Firms, he argued, were “acquiring the technical capacity to replace humans with computers in a rapidly widening range of ‘thinking’ and ‘deciding’ tasks,” and within twenty-five years would be able to substitute machines “for any and all human functions in organizations.” He expected artificial intelligence to eliminate the computer specialist altogether. That was 1960.

The software factory and the surgical team

When languages failed to eliminate programmers, management tried organization. The System Development Corporation, builder of the SAGE air defense software, rejected the “nostalgic” notion that programmers were different from other industrial workers and organized itself as a “software factory”: replaceable parts, simple repetitive tasks, a strict division of labor. Programmers were to be machine operators, “trained, but only in the basic mechanisms of implementing someone else’s design.” It required more programmers, not fewer, but they were meant to be cheaper and interchangeable. A 1969 management guidebook captured the aspiration: the successful computer manager was “one whose grasp of the job is reflected in simple work units that are in the hand[s] of simple programmers; not one who, with control lost, is held in contempt by clever programmers.” The problem to be solved was not software. It was autonomy.

The most revealing episode, for present purposes, is the chief programmer team. Developed at IBM by Harlan Mills and popularized by Fred Brooks as the “surgical team,” the CPT inverted the factory model. Instead of a horde of interchangeable novices, it placed a single expert “surgeon” at the center, surrounded by a support staff of copilots, toolsmiths, testers, and “language lawyers.” All communication passed through the chief, and a “development support library” allowed him to “exercise a wider span of control over the programming, resulting in fewer programmers doing the same job.”

If that sounds like an engineer orchestrating a fleet of agents, it should. The agentic model is the chief programmer team with the support staff replaced by language models. Even the titles are recognizable: Brooks’s “copilot” has been in use since 2021.

It is worth remembering why the CPT did not take over the industry. Chief programmers were rare and expensive, their organizations became dangerously dependent on them, and they disrupted lines of managerial authority. “The CPT perpetuates the prima donna image of the programmer,” complained one critic. Within a decade, textbooks were proposing a “revised” chief programmer team led by a project manager rather than a technical specialist.

Why it never works

Every generation of this story has its silver bullet: structured programming, fourth-generation languages, CASE tools, low-code platforms, each promising to let the business user bypass the programmer. Brooks’s 1987 essay “No Silver Bullet” was written in exasperation at this pattern, and was promptly answered by one entitled “There Is a Silver Bullet.”

The reason the bullets keep missing was identified early. As Willis Ware observed in 1965, “what we really are unhappy with is the total programming process, not programming (i.e., writing routines) per se.” Languages reduced the clerical work of programming, but they did not shorten the thinking. The hard part of building an accounting system was never the code. It was understanding the existing accounting department, its undocumented procedures and office politics, and translating that mess into something a machine could execute. Software is a heterogeneous technology, and the labor it requires is correspondingly heterogeneous.

So automatic programming did not eliminate programmers. It elevated them. Freed from the tedium of machine coding, programmers moved up into analysis and design, acquired new titles, and the shortage persisted, because the skill that was scarce was never the one that had been automated. The software crisis was declared, in nearly identical language, in 1968, 1979, 1987, and 1999. Its persistence is the best evidence that it was never primarily a technical problem.

The agentic version

None of this means the current tools are G-WIZ compilers. Language models really do write code. But the first returns on the agentic experiment are in, and they look remarkably like the returns on every previous one.

Start with the timetable. The prediction was ninety percent within six months. The best available measurement, a study of thirty million Python contributions on GitHub published in Science this past January, found that by the end of 2024 roughly a third of new functions written in the United States were AI-assisted, and that the resulting productivity gain was about 3.6 percent.

More interesting is who got the gain. Less experienced developers used AI more heavily, for 37 percent of their code against 27 percent for veterans, but the productivity improvement came almost entirely from the experienced. “Beginners,” one of the authors observed, “hardly benefit at all.”

A randomized trial published by METR in July 2025 is more striking still. Sixteen experienced open-source developers worked real issues in their own repositories, with and without AI tools. With them, they took 19 percent longer. They believed, both before and afterward, that AI had made them about 20 percent faster.

(A larger follow-up found effects indistinguishable from zero, which the brochure did not promise either.) Stack Overflow’s 2025 survey agrees: four in five developers now use AI tools, fewer than a third trust their output, and two-thirds spend more time fixing code that is “almost right, but not quite.”

Almost right is the operative phrase. Like the output of the first compilers, the agent’s code must be inspected and fixed by someone who could have written it. A study of twenty-three thousand AI-assisted pull requests presented this spring found that inexperienced “vibe coders” submitted larger changes with a 31 percent lower acceptance rate, which drew four and a half times as many review comments and took five times as long to resolve. Novices, the authors conclude, “focus on generating more code while shifting verification burden onto reviewers.”

The costs of software have been moved downstream, onto the review and maintenance work the industry has always valued least, and onto its most skilled people.

The tool that was to let managers do their own programming, in other words, is most useful to the programmers it was meant to replace and least useful to the managers and novices it was meant to empower. The division of labor remains Goldstine and von Neumann’s: the human writes the specification, which is the flowchart, and the agent “reduces the flow chart to the specific instructions.” If the flowchart were sufficient, coding would never have been a black art. What the agent demands of its supervisor is precisely the judgment automatic programming was supposed to make unnecessary.

Where the data do show movement is at the bottom of the ladder. Erik Brynjolfsson and his colleagues, tracking payroll records for millions of American workers, find no economy-wide displacement by AI. But employment of twenty-two to twenty-five year olds in the most exposed occupations, software development prominent among them, now sits roughly a fifth below where it would otherwise be, and the mechanism is not layoffs but reduced hiring. Experienced workers show no gap at all.

Every regime of software production has depended on an apprenticeship it never formally acknowledged. The software factory needed its horde of trainees; the surgical team needed a copilot who might one day become a surgeon; programmers have always learned their trade on the job. The agentic firm is dispensing with the bottom rungs of that ladder while remaining entirely dependent on the top. The 1970s objection to the chief programmer team, what happens when the superprogrammer takes a better offer, now has a sequel: what happens when no one is being trained to replace him?

The hierarchy, then, is reconstituting itself one level up. The “AI engineer” who supervises agents is the chief programmer, the systems analyst, and the planner under a new name. If the past is any guide, the role will prove rarer, more expensive, and less manageable than its promoters expect, and someone will soon propose a revised version in which the supervisor is a project manager rather than a technical specialist. Somewhere, a brochure is already being written for the tool that will eliminate the AI engineer.

The programmers of the 1960s were never quite professionals, never quite managers, and never quite clerks. I described them in the book as technicians: mediators between the technical and social architectures of the organization, granted autonomy grudgingly, resented for the dependence they created, and wielding power out of proportion to their official status. That is a durable position, and I do not think agents will abolish it. They will change who occupies it, what it is called, and how it is paid; those are the questions worth watching. Whether the computer can program itself is not among them. We have been told that it can since 1954.

Follow

• 1
  Simone Daniotti, Johannes Wachs, Xiangnan Feng, and Frank Neffke, “Who Is Using AI to Code? Global Diffusion and Impact of Generative AI,” Science (2026), doi:10.1126/science.adz9311. ↩︎
• 2
  Joel Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, July 10, 2025, arXiv:2507.09089. The follow-up is METR, “We Are Changing Our Developer Productivity Experiment Design,” February 24, 2026. ↩︎
• 3
  Stack Overflow, 2025 Developer Survey, July 29, 2025. ↩︎
• 4
  Syed Ammar Asdaque et al., “Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding,” MSR ’26, arXiv:2602.23905. ↩︎
• 5
  Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence,” Stanford Digital Economy Lab, updated 2026. ↩︎

One question I get quite often about my work is “how many programmers were there in [year X]?” As I have written about briefly on this site, and more extensively in the book, this is actually a very complicated question. We had electronic digital computers years before we had a well-established vocabulary to describe them, and now commonplace words like “software” and “programmer” had to be invented. Even then, what exactly counted as “programming” and therefore who counts as a “programmer” were never well settled, and to this day continue to be disputed (see, for example, Miriam Posner’s Javascript is for Girls article). The Bureau of Labor Statistics did not start tracking computer work until 1972, and have adjusted their categories several times since then.

A version of this question that has been coming up more frequently is “how many programmers were women?” This is an even more complicated question, because as little as we have solid data on programmer labor as a whole, even less of this data is broken down by gender.

That being said, in The Computer Boys Take Over I do state the following:

Contemporary estimates suggest that throughout the 1960s at least thirty percent of working computer programmers were women. One study puts the figure closer to fifty percent.¹Ensmenger, The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise (MIT Press, 2010), p. 237.

A close reading of the sentence in question suggest that it is a highly qualified statement about contemporary perceptions, and not an absolute claim about percentages. But it since these percentages were so outside of the (at that time) contemporary wisdom about women in computing, it is worth breaking down the evidence I used to justify this sentence.

My immediate source in The Computer Boys for this claim was a 1974 report by the industry analyst Richard Canning. For more than a decade Canning published the influential EDP Analyzer newsletter, and often wrote about the growing labor market for computer programmers. In his 1974 discussion of “Issues in Programming Management,” Canning references Joel Aron, the General Manager of IBM Programming Systems Development, and says the following: “Aron says that about one-half of the programmers are women, and that the number of women managers is rising rapidly.”²Canning, Richard. 1974. “Issues in Programming Management.” EDP Analyzer 12 (4): 1–14. Canning, one of the most informed industry observer of the era, repeats this claim without comment or skepticism.

Canning’s source for the Aron quote is actually another contemporary report from the industry journal Infotech. A year previously, Infotech had published a massive 526 page report on “Computing Manpower” that included presentations and invited papers from eighteen industry leaders. The 50% estimate actually appears in this volume three times. The first is in the report from Joel Aron quoted by Canning, of which the relevant sentences are:

Of the programmers, about half are female; and the number of female managers is rising rapidly. At one time, when I had a line management division in the organization, two of the five key managers were women and, under them, about a third of the managers were women. Our experience, which I imagine is fairly typical, is that there is absolutely no difference in the performance of men and women in similar jobs.³Aron, Joel. 1973. “Manpower Control in Large Computer Projects.” In Computing Manpower : International Computer State of the Art Report, edited by C. Bunyan, 327–47. Maidenhead: Infotech Information Ltd.

While it is perhaps not necessary to defend the knowledge and experience of an IBM Vice President who had been with the company since 1954 and who was, in addition to having been the manager of several large software development groups at IBM, also the head of the IBM FSC Programming Laboratory and the editor-in-chief IBM sponsored Systems Programming Series (published by Addison-Wesley through at least the early 1980s), there is an earlier reference to the 50% figure. In a 1964 article in the NY Times entitled “Computers Are Getting Ideas From Women: I.B.M. the Leader in Employing Girls as Programers,” Vartanig Vartan suggests that 1200 out of IBM’s 2500 computer programmers were women. 1200/2500 is not quite 50%, but as Joel Aron might argue, close enough for Federal Systems work…

The second reference to a 50% figure in the Infotech report comes from a report by Suzette Harold on “The Role of Women in Computing.” The specific quote is from page 199 of the report, and reads:

Many installations now have more than 50% of women in their programming teams and indeed, commercial programming is in danger of becoming another “women’s job.” I say “in danger” because employers in the past have seen in women a source of cheap labor and once women are segregated into what thereafter becomes known as women’s jobs, equal pay and conditions are inhibited.⁴Harold, Suzette M. 1973. “The Role of Women in Computing.” In Computing Manpower : International Computer State of the Art Report, edited by C. Bunyan, 195–215. Maidenhead: Infotech Information Ltd.

Like Joel Aron, Suzette Harold was well-situated to comment on the role of women in computing. Harold served on the Council of Software Houses Association, a U.K.-based software industry organization. She had previously worked on software development at the Atomic Energy Research Establishment, the Rutherford High Energy Laboratory, and the Atlas Computer Laboratory. She was on the scientific staff at the Science Research Council. Like Aron, she had broad experience in the industry.

At the time she presented her findings on women in computing in the 1973 Infotech report, Harold was an executive at F International, which was a software services consulting firm that eventually would become a multi-million dollar firm with hundreds of clients spanning both the U.K. and the European continent. F International employed almost exclusively female programmers.

F International was not the only early software development company to take advantage of the large number of women working in computing in this period. It was itself a subsidiary of Freelance Programmers, a company founded in 1962 by Stephanie “Steve” Shirley. Freelance Programmers was one of the first consulting software development firms, and one of the most successful. When by-then-Dame Stephanie Shirley sold the company in 2007, it was worth £400 million. In 1962, when Freelance Programmers was helping to establish the software industry, it employed only women programmers. It only hired its first male programmers in 1975 when, ironically, it was forced to by the passage of Sex Discrimination Act in the UK. At that point there were 300 women working as programmers at Freelance. So, in 1962 we have a company in which the actual, well-documented percentage of female programmers is 100%.⁵Shirley, Stephanie, and Richard Askwith. 2013. Let It Go: The Story of the Entrepreneur Turned Ardent Philanthropist.

The third reference to 50% figure in the Infotech report is by the editor of the report C.J. Bunyan, who in his lengthy (150 page) introduction/summary to the report highlights both Aron and Harold’s assessments. Bunyan, who edited and authored numerous industry reports from this period, seemingly found nothing to disagree with in these estimates.

Although I do not cite them in The Computer Boys, there are other references to the 50% figure outside of the Infotech report. A 1964 article in the Guardian by Maureen Eppstein argued that 50% of programmers in the UK were women.⁶Eppstein, Maureen. 1964. “The Computer Women.” Guardian, January 31, 1964. I first discovered this reference in Janet Abbate’s 2012 book Recoding Gender, which is based on both historical research and a series of fifty-two oral histories she conducted with women who had worked as programmers in both the US and UK in the early decades of computing.⁷Abbate, Janet. 2012. Recoding Gender: Women’s Changing Participation in Computing. History of Computing. London, England: MIT Press. On the very first page of the first chapter of that book, Abbate quotes Paula Hawthorn, who worked as a programmer at Texaco in the mid-1906s. According to Hawthorn,

It never occurred to us that computer programming would eventually become something that was thought of as a men’s field. At that time … it was at least half women.⁸Abbate, p. 1

Note here both the (again, contemporary to the late 1960s) claim that 50% of all programmers were women and Hawthorn’s expressed surprise at her realization that programming was anything other than women’s work.

I should note that Janet Abbate herself does not endorse Hawthorn’s claim as being a true reflection of the actual percentage of women in computing in this period. To the degree that she even attempts to provide numerical estimates, she follows the Bureau of Labor Statistics numbers from the early 1970s.

But Hawthorn is not the only woman cited by Abbate who clearly believed that the percentage of programmers in the 1950s who were women was significant. As Elsie Shutt, another pioneering innovator in the software development consulting industry expressed in her interview with Abbate,

It really amazed me that these men were programmers, because I though it was women’s work.”

In this quote Shutt appears to be talking about her time as a programmer at Raytheon in the early 1950s. By 1957, Shutt had been forced to leave the company because she had gotten pregnant, and had founded Computations, Inc., which like Freelance Programmers employed 100% women. Shutt ran her company successfully for more than four decades. As far as I know, none of the employment records that would definitely document this claim remain in existence, but this is typical of the corporate records of smaller companies, and see no reason to doubt Schutt’s assessment of the state of the programming industry in the era that she helped define it.

And so we see that there are multiple, plausible claims from the 1960s that the percentage of computer programmers who were women was as high as (or even more than) 50%. There are also lower estimates. In a 1966 study of programming proficiency, Raymond Berger and Robert Wilson of the Electronic Personnel Research Group at the University of Southern California identified 28% of the 366 government civil service programmers as being women.⁹Berger, Raymond M., and Robert C. Wilson. 1966. “Correlates of Programmer Proficiency.” In Proceedings of the Fourth SIGCPR Conference on Computer Personnel Research – SIGCPR ’66. New York, New York, USA: ACM Press. This is the source I relied on for my lower abound of roughly 30%. Of course, without knowing exactly how Berger and Wilson selected their sample, it is uncertain how well representative their data represents the industry as a whole, but that is the best data I had to go on at the time, and their report was published in the Association for Computing Machinery (ACM) SIGCPR (Special Interest Group in Computer Personnel Research), the most relevant and prestigious professional publication in this area. When I was researching The Computer Boys, it was not as easy to access historical materials as it is today. And even if it had been, there are simply not many sources of reliable, quantified data from the 1950s and 1960s.

The first official government statistics on programmer employment comes from 1956 report by the US Labor Department on “Employment Opportunities for Women Mathematicians and Statisticians.” “It was a fact,” according to this report, “that many industrial laboratories employed only women in their computing groups; others employ a high percentage of women.” (from Abbate, 65, emphasis mine) The focus of this study on college-educated mathematicians and statisticians seems to suggest that it is talking about higher-level computing occupations such as programming and systems analysis, but it is also true that the term “computing group” potentially covers a variety of types of work, some of which were almost exclusively feminized (such as key-punch operator, or the now obsolete category of “computer operator”), and none of which we would today consider to be aspects of computer programming. That being said, the report also cites specifically one example of a laboratory in which “67% of the programming staff were women.”

The United States Bureau of Labor Statistics did not begin tracking programmer labor until 1970, and their estimate of the percentage of women in computing was 23%. As I (and others) have argued elsewhere, there are numerous reasons to believe that their data under-represents the number of women working as programmers (and, for that matter, the number of men)¹⁰See Ensmenger, The Computer Boys Take Over, as well as Loseke, Donileen R., and John A. Sonquist. 1979. “The Computer Worker in the Labor Force: New Occupations and Old Problems.” Sociology of Work and Occupations 6 (2): 156–83; Greenbaum, Joan. 1976. “Division of Labor in the Computer Field.” Monthly Review 28 (3): 40.Kraft, Philip, and Steven Dubnoff. 1986. “Job Control, Fragmentation, and Control in Computer Software Work.” Industrial Relations 2 (25). Bruce Gilchrist, who wrote extensively about labor issues in the computer industry and who held executive positions both in the Association for Computing Machinery (ACM) and the International Federation of Information Processing Societies (IFIPS), reviewed the 1970 BLS report and noted that the BLS numbers were significantly lower than earlier industry estimates.¹¹Gilchrist, Bruce, and Richard E. Weber. 1974. “Enumerating Full-Time Programmers.” Communications of the ACM 17 (10): 592–93. Even prior to its publication, he had criticized the BLS report as being “based on relatively little firm data” and noted particularly the “lack of widely accepted standard definitions for occupations such as programmer, systems analyst, computer operator, etc.”¹²Gilchrist. 1969. “Manpower Statistics in the Information Processing Field.” Computers & Automation. These fundamental ambiguities, combined with a reliance on self-reporting and the tendency of some workers to inflate their job titles, meant that some forms of work systematically misrepresented. He notes particularly errors in the categorization of keypunch operators and computer operators, which were roles particularly associated with women.¹³Weber, Richard E., and Bruce Gilchrist. 1975. “Discrimination in the Employment of Women in the Computer Industry.” Communications of the ACM 18 (7): 416–18.

Over the course of the 1970s, Gilchrist and his co-author Richard Weber attempted to develop a better data set on programmer employment, consistently arguing that the BLS data was insufficient. But even as they developed alternative and more inclusive measures of programming labor, they acknowledged that their own data sources also under-represented the “significant and probably growing amount of programming” that we being performed by people and organizations who were not fully visible in the formal statistics.¹⁴Weber, and Gilchrist. 1972. “Employment of Trained Computer Personnel: A Quantitative Survey.” Communications of the ACM. Often they relied on a different data set from the BLS Area Wage Studies which excluded, among other groups, employees of educational institutions, scientific programmers, agricultural employees, and the self-employed. As far as I am aware, Gilchrist and Weber make only one attempt to estimate the percentage of female programmers, and they highly qualify this in the same way that they do all of their estimates. In that study, their figure of 21% corresponds closely to the BLS statistic.¹⁵Weber, Richard E., and Bruce Gilchrist. 1975. “Discrimination in the Employment of Women in the Computer Industry.” Communications of the ACM 18 (7): 416–18. But as they point out in their 1974 attempt at “Enumerating Full Time Programmers,” the lack of standard categories and structural biases in the data meant that, at best, they could “paint only a hazy and incomplete picture of the employment situation in computer related occupations.”¹⁶Gilchrist, Bruce, and Richard E. Weber. 1974. “Enumerating Full-Time Programmers.” Communications of the ACM 17 (10): 592–93.

The fact that even basic terms like “software” and “programming” were being actively defined and negotiated during the 1950s makes it difficult to rely on job titles or self-descriptions of work. Consider the female operators of the ENIAC, the so-called “ENIAC Girls” (the use of such gendered language, while unpalatable to modern sensibilities, is essential to understanding the gender dynamics of early computing): as both Janet Abbate and Thomas Haigh have correctly noted, both “coder” and “programmer” are anachronisms when applied to the work these women did. Such concepts and categories did exist at the time. And yet the work these women did undeniably helped shape the practices that would become programming, and many of them would go on to work in roles that would become labeled as “programmer.” And they most definitely saw themselves as pioneering programmers.¹⁷Bartik, Jean, Jon T. Rickman, and Kim D. Todd. 2013. Pioneer Programmer. Truman State University Press. Do we count them as programmers? I would, but I can also see the argument for not doing so. If we do consider them to be computer programmers, than for that brief moment in history, at that particular (but highly visible and influential) place, the percentage of programmers who were women was 100%. As we have seen, much depends on which moment and which organization one chooses as a representative snapshot.

All this being said, the “between 30-50%” figure so often cited from The Computer Boys was never meant to be a definitive estimate of the percentage of working programmers who were women. In my research I generally resist trying to precisely enumerate the number of computer programmers (male or female) working in the period covered by the book (which is roughly 1946-1968). In fact, a key argument of the book is that it would be almost entirely pointless to even attempt to do so, since this is the period during which the very categories of what constituted “computer work” were being actively negotiated. Who “counted” as a computer worker was a highly contested question. Much of the scientific and informational work that today we associate with computers did not originate with computing (data processing was a well-established industry long before the advent of electronic computing, and IBM was a globally dominant information technology company decades before it manufactured its first computer), and many of those who happened to use computers in their work still identified primarily as engineers, scientists, systems analysts, or professional managers. Not only were there no industry-standard job categories for computer work in this period, practitioners themselves used a variety of terms to describe what they did and who they were. Trying to be too precise about the total number of “computer workers” would be a pointless exercise, and in my written work I try to be careful to avoid doing so. In fact, I embrace this ambiguity, in large part because I believe is more authentic to the experience of my historical actors. But that computer programming was seen in the 1950s and 1960s as uniquely accessible to women — in stark contrast to later periods —is undeniable. (For more on my historical work on gender and computing, see the posts YOUR CAREER IN COMPUTER PROGRAMMING and THE COMPUTER GIRLS? as well as my articles “‘Beards, Sandals, and Other Signs of Rugged Individualism’: Masculine Culture within the Computing Professions“¹⁸Ensmenger, Nathan. 2015. “‘Beards, Sandals, and Other Signs of Rugged Individualism’: Masculine Culture within the Computing Professions.” Osiris 30 (1): 38–65. and “Making Programming Masculine.”¹⁹Ensmenger, Nathan. 2010. “Making Programming Masculine.” In Gender Codes: Why Women Are Leaving Computing. ). See also the work of Janet Abbate and Mar Hicks, among others.

Follow

• 1
  Ensmenger, The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise (MIT Press, 2010), p. 237. ↩︎
• 2
  Canning, Richard. 1974. “Issues in Programming Management.” EDP Analyzer 12 (4): 1–14. ↩︎
• 3
  Aron, Joel. 1973. “Manpower Control in Large Computer Projects.” In Computing Manpower : International Computer State of the Art Report, edited by C. Bunyan, 327–47. Maidenhead: Infotech Information Ltd. ↩︎
• 4
  Harold, Suzette M. 1973. “The Role of Women in Computing.” In Computing Manpower : International Computer State of the Art Report, edited by C. Bunyan, 195–215. Maidenhead: Infotech Information Ltd. ↩︎
• 5
  Shirley, Stephanie, and Richard Askwith. 2013. Let It Go: The Story of the Entrepreneur Turned Ardent Philanthropist. ↩︎
• 6
  Eppstein, Maureen. 1964. “The Computer Women.” Guardian, January 31, 1964. ↩︎
• 7
  Abbate, Janet. 2012. Recoding Gender: Women’s Changing Participation in Computing. History of Computing. London, England: MIT Press. ↩︎
• 8
  Abbate, p. 1 ↩︎
• 9
  Berger, Raymond M., and Robert C. Wilson. 1966. “Correlates of Programmer Proficiency.” In Proceedings of the Fourth SIGCPR Conference on Computer Personnel Research – SIGCPR ’66. New York, New York, USA: ACM Press. ↩︎
• 10
  See Ensmenger, The Computer Boys Take Over, as well as Loseke, Donileen R., and John A. Sonquist. 1979. “The Computer Worker in the Labor Force: New Occupations and Old Problems.” Sociology of Work and Occupations 6 (2): 156–83; Greenbaum, Joan. 1976. “Division of Labor in the Computer Field.” Monthly Review 28 (3): 40.Kraft, Philip, and Steven Dubnoff. 1986. “Job Control, Fragmentation, and Control in Computer Software Work.” Industrial Relations 2 (25). ↩︎
• 11
  Gilchrist, Bruce, and Richard E. Weber. 1974. “Enumerating Full-Time Programmers.” Communications of the ACM 17 (10): 592–93. ↩︎
• 12
  Gilchrist. 1969. “Manpower Statistics in the Information Processing Field.” Computers & Automation. ↩︎
• 13
  Weber, Richard E., and Bruce Gilchrist. 1975. “Discrimination in the Employment of Women in the Computer Industry.” Communications of the ACM 18 (7): 416–18. ↩︎
• 14
  Weber, and Gilchrist. 1972. “Employment of Trained Computer Personnel: A Quantitative Survey.” Communications of the ACM. ↩︎
• 15
  Weber, Richard E., and Bruce Gilchrist. 1975. “Discrimination in the Employment of Women in the Computer Industry.” Communications of the ACM 18 (7): 416–18. ↩︎
• 16
  Gilchrist, Bruce, and Richard E. Weber. 1974. “Enumerating Full-Time Programmers.” Communications of the ACM 17 (10): 592–93. ↩︎
• 17
  Bartik, Jean, Jon T. Rickman, and Kim D. Todd. 2013. Pioneer Programmer. Truman State University Press. ↩︎
• 18
  Ensmenger, Nathan. 2015. “‘Beards, Sandals, and Other Signs of Rugged Individualism’: Masculine Culture within the Computing Professions.” Osiris 30 (1): 38–65. ↩︎
• 19
  Ensmenger, Nathan. 2010. “Making Programming Masculine.” In Gender Codes: Why Women Are Leaving Computing. ↩︎

When I teach the history of Silicon Valley, I open my lecture with a clip from the 1973 James Bond film Live and Let Die.  My point it not to talk about Bond, but rather his wristwatch — a Pulsar LED, one of the first of our mobile digital devices.  Understanding the unique moment in history when digital watches still seemed like a pretty neat idea is key to understanding the strange and powerful economics of the semiconductor industry.

In recognition of the passing today of Roger Moore, here is an excerpt from Computer: A History of the Information Machine that I wrote about the history of the digital watch:

In the 1973 film Live and Let Die, the stylish secret agent James Bond traded his signature wristwatch, a Rolex Submariner, for the latest in high-tech gadgetry, a Hamilton Pulsar digital watch. Unlike a traditional timepiece, the Pulsar did not represent time using the sweep of an hour-and-minute hand; instead, it displayed time digitally, using a recently developed innovation in microelectronics called the light-emitting diode, or LED. In the early 1970s, the glowing red lights of an LED display represented the cutting edge of integrated circuit technology, and digital watches were such a luxury item that, at $2100 for the 18-karat gold edition, they cost more even than an equivalent Rolex. The original Pulsar had actually been developed a few years early for the Stanley Kubrick film 2001: A Space Odyssey, and, for a time, access to this technology was limited to the domain of science fiction and international espionage.

Within just a few years, however, the cost (and sex appeal) of a digital watch had diminished to almost nothing. By 1976 Texas Instruments was offering a digital watch for just $20 and, within a year, had reduced the price again by half. By 1979 Pulsar had lost $6 million dollars,  had been sold twice, and had reverted back to producing more profitable analogue timepieces. By the end of the 1970s, the cost of the components required to construct a digital watch had fallen so low that it was almost impossible to sell the finished product for any significant profit. The formerly space-age technology had become a cheap commodity good—as well as something of a cliché.

The meteoric rise and fall of the digital watch illustrates a larger pattern in the unusual economics of microelectronics manufacturing. The so-called planar process for manufacturing integrated circuits, developed at Fairchild Semiconductor and perfected by companies like Intel and Advanced Micro Devices (AMD), required a substantial initial investment in expertise and equipment, but after that the cost of production dropped rapidly. In short, the cost of building the very first of these new integrated circuit technologies was enormous, but every unit manufactured after that became increasingly inexpensive.

The massive economies of scale inherent in semiconductor manufacture—combined with rapid improvements in the complexity and capabilities of integrated circuits, intense competition within the industry, and the widespread availability of new forms of venture capital—created the conditions in which rapid technological innovation was not only possible but essential. In order to continue to profit from their investment in chip design and fabrication, semiconductor firms had to create new and ever-increasing demand for their products. The personal computer, video game console, digital camera, and cellphone are all direct products of the revolution in miniature that occurred in the late 1960s and early 1970s. But while this revolution in miniature would ultimately also revolutionize the computer industry, it is important to recognize that it did not begin with the computer industry. The two key developments in computing associated with this revolution—the minicomputer and the microprocessor—were parallel strands unconnected with the established centers of electronic digital computing.

Follow