Pushing Professionalism

This essay is reproduced here as it appeared in the print edition of the original Science for the People magazine. These web-formatted archives are preserved complete with typographical errors and available for reference and educational and activist use. Scanned PDFs of the back issues can be browsed by headline at the website for the 2014 SftP conference held at UMass-Amherst. For more information or to support the project, email sftp.publishing@gmail.com

Pushing Professionalism (or Programming the Programmer)

by Phil Kraft  

‘Science for the People’ Vol. 6, No. 4, July 1974, p. 26 – 29

This article was written as part of a continuing discussion of the technical workforce. See Science for the People, May 1973, “An Examination of Some Myths and Contradictions Concerning Engineers” and “Technical Intelligence and the Capitalist Division of Labor.” We encourage response, particularly from computer programmers.

Zap! You’re A Professional!

Computer programmers and other computer specialists are about to become professionalized after fewer than thirty years as a distinct occupational group. What makes the professionalization of programmers especially interesting is the fact that programmers are about to be professionalized behind their backs. In fact, what turns out to be the most intriguing aspect of the professionalization process is not that it’s taking place, but who’s pushing it. If programmers themselves seem largely indifferent to the question of professional status, programmers’ employers have shown the most lively sort of interest. 

But something is amiss here. Why would employers (or more accurately, their hired managers) promote attitudes among their employees which, on the surface, appear at odds with the interests of management? After all, professionals historically have been monopolistic and exclusive, particularly with regard to controlling their workplace and regulating their income. Both areas, of course, are regarded by management as their exclusive preserves. 

There is a reasonably straightforward explanation of management’s push for programmer professionalization. It has to do with, first, the needs of managers in controlling their workers—in this case, computer specialists—and secondly, with the real versus the official—and deceptive—meaning of the term “professional.” 

The Emergence of Programming 

Computer programming is a new occupation with few if any antecedents in other occupations. The twin developments of technological complexity and continuously expanding applications of computers have generated parallel developments in the skills needed to operate the machines and to manage their applications. For all its complexity, the computer has to be “instructed” how to compute, what to compute, and how to display the results of the computations in some useful way. Programmers are the people who supply such carefully detailed step-by-step instructions (the “program”) in a format (the “language”) accepted by the circuitry of the computer so that it will perform exactly the kinds of operations desired. 

The complexity of the programming task varies with the complexity of the language and its “logic,” the extent and nature of the information to be processed, the kinds of calculations desired as well as the skills of the programmer. On the whole, it remains a time-consuming, errorprone, almost handicraft activity, with aspects, as Daniel Freedman has put it, of both magic and art. The slowness and vulnerability to error of programming are in sharp contrast to the speed and efficiency of the machines themselves. But it is precisely the efficiency and accuracy of the machine which are dependent on the skills of the programmer. However slow, error-prone and human the programmer may be, s/he has thus acquired a critical, if problematic, role in a critical industry. 

Virtually all programmers and related computer specialists are employees. In this they are no different from the great majority of American workers. Programmers are, however, different in one significant way from most other employees. For most other workers, managers have successfully developed techniques of organizing the work situation itself—the workplace—to act as regulators and manipulators of the workers. The assembly line eliminates the need for a large-number of foremen by forcing line workers to adjust the movements of the human body to the (management-controlled) pace of the moving belt. Computer-controlled dictation equipment simultaneously sets the pace for and monitors the output of clerk-typists. The teen-ager who serves you your Big Mac must enter the exact order in the exact place on the correct inventory tab and smile at the same time, customer after customer after customer—or lose her/his job. 

What all these techniques have in common is that the very rhythm of the work activity, the minute by minute relationships between workers and their work and between workers and each other have been arranged—deliberately and carefully—to make sure that employees do exactly what their managers want them to.1

Programmers, although every bit as much employees as the assembly line worker or the typist or fast food server, have successfully resisted attempts at managerial control via structuring of their workplace—at least up to now. But if they have maintained, compared to other employees, some degree of independence of managers, it is not because managers haven’t tried to regulate programmers in the same manner they’ve regulated non-programmer workers. Various ways of organizing the programming task—”top-down programming,” “chief-programming teams,” “modular programming” and other similar-sounding approaches—have been used by management to structure the social organization of the programming task to make it look as much as possible like the conventional bureaucratic hierarchy of the factory or office. 

For a number of reasons, such managerial efforts at best have been only partially successful. Programming is an acquired skill which is both relatively hard to learn and even harder to use well. Moreover, because it is a mind-skill, there are few hard-and-fast rules of behavior which managers can compare against an efficiency expert’s model in order to check performance. Similarly, most managers, even those who were once programmers themselves, aren’t capable of judging when a program is written well or badly. In most cases, they have to take what the programmer offers. 

Programmers are therefore something of an anomaly: they are employees, but they are in a position to control how they will go about doing their programs—the final product—as well as the form the final product will take. Not surprisingly, managers and employers find this an intolerable situation. It is intolerable not because employee workplace control is less efficient (cf., Gerald Weinberg, who makes impressive claims that programmer control of the workplace is significantly more, not less, efficient2) but because employee control of the workplace threatens managerial authority. In this sort of situation, managers and employers will accept even a certain amount of inefficiency in order to re-enforce or preserve their dominance of the programming work activity. 

But, as we’ve seen, the traditional methods of employee manipulation have not yet been successfully adapted to the peculiar situation of programmers. While these traditional methods are being debugged, an alternative managerial strategy has emerged, the strategy of “professionalizing the workforce.”

Professions Without Professionals

An occupation which is still new, vaguely defined and meaningful only to its members is, as we’ve seen, in an unusually good position to defend its members against managerial control. It is also one which is likely to bring out everything in the managers’ arsenal of worker manipulation. Programmers may be critical employees, but critical or not, the whole carefully contrived balance of managerial superiority is endangered if programmers can function perfectly well without programmer managers. From the managers’ point of view, it is vital that programmers be located within the hierarchical structure of the employing organization in order to effectively control them. 

If the conventional devices of external control—close managerial supervision or the structuring of the organization of work itself—are not effective, one alternative is to substitute internal for external control. “Professionalizing” programmers becomes a handy way of pulling off the trick. We get some idea of this from observing where the major discussions of programmer professionalization take place and who typically does the discussing. Most such discussions take place in the pages of DATAMATION or INFOSYSTEMS or other trade journals. If these are read at all, they are read by managers and not by programmers. In the same manner, the organizations actively engaged in a systematic effort to promote professionalization are virtually all industry organizations, e.g., the Association for Computer Machinery through its Special Interest Group for Computer Personnel Research. On the other hand, if a survey of mine is representative of the general programmer population, working programmers neither read trade journals nor belong to any occupational organizations. 

How can managers use “professionalism” as a way of getting programmers to police themselves? Part of the answer has to do with the historical origins of professionals and part has to do with the way managers have modified the original concept to suit their own ends. 

The Career of a Myth

The occupation which most of us have in mind when speaking about professionals is that of the physician. There is good reason for this. Physicians (as well as lawyers and pharmacists) emerged as a distinct occupational group for the first time only during the Middle Ages. Before physicians became physicians they were simply barbers who also applied bloodsuckers for the relief of assorted aches and pains. The appliers of leeches gradually organized themselves into occupational organizations patterned after those of their fellow small tradesmen and artisans—the guild. The role and subsequent influence of the guild organization are very important. All guilds, whether of barbers, masons, weavers, or physicians, had a few basic functions: (1) to restrict entry into the occupation; (2) to eliminate competitive practices among guild members; and (3) to enforce monopoly control over the performance—and the rewards—of the services of guild members. 

Medieval guilds were, in other words, made up of independent, self-employed entrepreneurs, who defined not only the content of their work but the conditions under which it was performed. Because they were small businessmen, guild members, including physicians, exchanged their services for fees, i.e., they sold them to those who could afford to pay. By doing so they re-enforced the existing inequalities of the society of which they were a part, providing important services to those who had the means and withholding them from those who simply needed them but could not afford to pay. 

Physicians, because they dealt with something as critical and emotion-charged as life and death, found themselves in a particularly happy position. Although they were little better than witch doctors, they could cajole, intimidate and deceive people about their health and their very lives. And since they ministered largely to the rich, the rich rewarded them not only with money but with special privileges as well. Gradually, they acquired the legal, i.e., state-enforced, right to first certify new practitioners and then to grant exclusive licenses. All of this, of course, strengthened their monopoly on the health business. In the meantime, the abilities of physicians remained akin to those of their barbering ancestors until well into the 19th century. Even then, the real advances in science which eventually turned medicine into something more than black magic were made by non-physicians, e.g., the discoveries of Pasteur, which were stoutly resisted by the certified and licensed practitioners who perceived the discovery of sepsis3 as a threat to their “professional” dignity. 

Contemporary physicians, to give credit where it is deserved, have gone beyond their predecessors and reconciled two contradictory tendencies. Starting in the 19th century they have absorbed the genuine scientific progress which began flowing at the rapid rate to which we have grown accustomed and they have perfected the guild as an organizational form unmatched by anything in the Middle Ages. Their monopoly control of the product (health services) is virtually complete, having either destroyed useful and legitimate competitors, e.g., midwives, or reduced them to marginal practitioners of a disreputable trade, e.g., osteopaths, or placed them firmly under their collective professional thumb, e.g., nurses. 

It is important to underline the implications of these historical roots of professionalism. They arose at least as much out of a desire to protect monopolitic privilege as a desire to extend useful knowledge (and to protect it against charletanism); they arose to protect the vested interests of what were essentially self-employed small businessmen, not highly skilled employees; and they ultimately helped re-enforce great social divisions by providing vital services to those on the top rather than those on the bottom. By the nineteenth century, when the first body of scientifically-based knowledge was only just starting to become part of the physicians’ tools, the basis of their “professional” status already had been long established by virtue of their political, not their occupational, skills. 

The programmer reading this may feel a trifle disturbed that the professional status managers have in mind for her/him has such unsavory origins. But a moment’s reflection will be enough to demonstrate how irrelevant the occupational organization of small businessmen is to people who are overwhelmingly employees. It may therefore be of small comfort—very small comfort—that the image of the professional that managers have in mind is different in some subtle but significant ways from the historical reality. 

It should be clear why managers, even as they push professionalism, can’t really tolerate programmers who resemble the prototypical physicians. Managers have therefore changed the definition of professional which, from their perspective, has all of the advantages of the old guild-like organization and none of its disadvantages. Professionalism for programmers, as it has emerged in management literature, means: the establishment of universal job descriptions and standards, formulated, of course, by personnel managers; common training programs; and a common certification process. On the other hand, the managers’ image does not include certification by an authority controlled by the programmers’ peers, but one controlled by their employers. It does not include licensing, nor, finally, does it foresee under any circumstances making independent entrepreneurs out of programmers. Management’s vision, in other words, is of a profession without professionals. 

The reasons are clear. A profession without professionals would allow managers to have their cake and eat it too. Job performance standards would be established—presumably at high “professional” levels—but the standards would be established by the managers, not the professionals. In effect, the managers’ notion of professional programmers is one which gives them and not the programmers the power to define what programming is. 

The Myth of a Career 

In practice, management has found some creative ways of imposing its particular vision of professionalism on programmers. Chief among these is the fragmenting of the programming task, hierarchically arranging the newly created fragments to parallel the conventional hierarchy which characterizes the rest of the employing organization, and then holding up “advancement” from one fragment to another as a form of “professional career.” Largely as a result of this, the programming activity is no longer undertaken by programmers. Instead, a whole list of new sub-occupations has emerged whose boundaries—and actual tasks—are vague and overlapping. Aside from whatever advantages it may or may not have for efficiency, increased productivity and so on, the division of labor created in a programming installation thus provides a distinct hierarchical structure masquerading as a career line for newly “professionalized” programmers. Managers have thus killed two birds with one stone: the personal aspirations of programmers can be channelled along clear-cut—if artificial—career paths and managers have been given a device that will enable them to make sure that they and not programmers will remain in charge of programming. Tasks have been broken down and are presumably more easily monitored, while at the same time the hierarchical structure of these tasks gives back to the manager his traditional carrot of controlling individual advancement in the organization. 

The trick is not a new one. School teachers until recently were kept in line by having them do it themselves. They were the classic example of how external regulation was made unnecessary by internal regulation based on abstract notions of a “professionalism” which had flexible meanings4. While it meant one thing to teachers (doing a good job) it meant another to their administrators (rejecting unionization and doing what they were told). The experience of school teachers is of immediate relevance to programmers. Teachers, like programmers and unlike physicians, have been from their beginnings employees, not independent entrepreneurs. Their training, certification, and licensing are not in their hands but ultimately in the hands of their employers. Again, this is similar to what is being proposed for programmers and just the opposite of what is true of physicians. Like programmers, too, the demands of their employers are vague, constantly changing, but always informed by a desire to standardize. 

The professional career ladder being manufactured for the programmer thus emerges as a white-collar variation of the assembly-line techniques of employee manipulation. Fragmenting the work and calling the fragments a career line inserts programmer employees into the conventional corporate organizational structure; it also provides a thoroughly internalized regulatory device, the desire to “advance up” an artificial career ladder. 

The critical question now is how will programmers resolve the emerging contradiction between their self-interest and management’s desire to facilitate a self-regulated workforce of programmers. Will the resolution take the form of passive acceptance of management’s version of “professionalism” while working conditions, hours and wages deteriorate? Will it take the form of a narrow trade unionism which calls itself professionalism but which seeks to defend the remaining special privileges of programmers to the detriment of other workers? Or will programmers begin to identify their self-interests in common cause with other workers who confront the same management — the secretaries, keypunch operators, janitors, machine operators, and production workers? The latter course of joining with other workers will occur only if politically conscious programmers actively struggle for it; otherwise some form of management-inspired professionalism is the only alternative. Although less virulant than sexism or racism, a professionalism which grants special privileges and status to a few skilled workers is one more weapon in management’s arsenal of divide and conquer.


>> Back to Vol. 6, No. 4 <<



  1. It can come as something of a shock to employees how matter of factly managerial discussions of the workplace and even the “engineering” aspects of the production process are couched in explicitly manipulative terms. Talk of “increased productivity”, “efficiency” and so on, has very often little to do with producing more product for less investment, but with ways of making sure workers don’t get out of hand. A useful review of some of the “classic” approaches to worker manipulation can be found in Peter Blau and W. Richard Scott, Formal Organizations, Chandler Publishing Company (San Francisco, 1962).
  2. Gerald M. Weinberg, The Psychology of Computer Programming. Van Nostrand Reinhold (New York: 1971)
  3. A poisoned state caused by absorption of bacteria from a region of infection, into the blood stream.
  4. Now that school teachers have seen through the device and have begun to unionize, their administrators (managers) have had to fall back on the older industrial methods of structuring the work to use against the workers. “Contract teaching” and the so-called “voucher system” are the educational establishment’s version of the assembly-line and piece-work.