“The guy in the room” is from Jim McCarthy in “The Dynamics of Software Development,” not Weinberg. Here’s a presentation where McCarthy discusses the problem.
How so? That book is from 1995. The Weinberg quote is from his book in 1971.
I’ve got the Kindle version of that book here, and a search for “commandment” turns up zero results. That’s why I went searching for another reference to that idea in other books, and found it in McCarthy’s book. Can you give a chapter reference or page reference to these 10 commandments? I’ve also got a paper copy of the Silver Anniversary edition. (I bought the Kindle one solely for this, because I got frustrated paging through the paper copy looking for this list of commandments.)
It looks like you are right! I am not exactly sure of the provenance of the exact text, then.
Thanks for this, I love the term “egoless programming” and it’s something I look for in good collaborators and strive for myself.
I’d recommend changing “guy in the room” to “person in the room” or “coder in the room,” since it’s good to be inclusive even when talking about bad qualities.
1 Like
This is really a timeless piece of very valuable information to any programmer.
Still, there is something i would like to add, from my personal experience:
Item 9., “Don’t be the coder in the corner” - while i think this is true, to an extent, it shouldn’t give people shame if they sometimes perform better when coding alone. Don’t put yourself in a position of unease for extended periods, just because you understand some 10 commandments of egoless programming that way. This should not be always, but in some task or project, i need to take my time to come up with a good solution, and while any solution should always be presented (and defended if necessary, and adapted from external input if necessary), sometimes it can be better to take your time with it, because of the other egos that might influence a solution to the worse, when doing so prematurely.
When you are an experienced programmer, you are your own worst critic, so make use of your strengths, know your strengths and don’t let people tell you otherwise. Let the results speak for themselves.
It always depends on the environment, but it should be your call to choose the right approach. You are the expert.
1 Like
I read your 10 Commandments of egoless programming with much personal interest.
In 1978 I encountered “improved programming technologies” and heard the term “egoless programming” as an ideological movement by corporate computer programming managers and their consultants to try to make mediocre computer programmers produce bug-free code that met specificatons. I called them: The mongoloid hoard.
I was working in IBM Poughkeepsie MVS development on the Real Storage manager. I was a junior grade employee: I had a gray plastic top desk (There were three grades of computer programmers: gray tops, fake wood tops and real wood desks). Sitting at my gray top one day, I overheard the people in my group with fake woodtop desks, in a walkthrough, humiliate – repeat: h-U-M-I-L-I-A-T-E a poor helpless programmer at the same low rank as I was, in a “walkthru” of his code. I had come to IBM with as a 6 year veteran of “systems programming” in the coroprate world; this unfortunate young man kept a Snoopy dog figurine on his desk and could not defend himself.
Everything had been converted from assembly language to a higher level language, PL/S (which is something like PL/1). My third line manager told me: We know you can do the job your way, but what do we do with all the other programmers who can’t tell an L from a LA? (“L” and “LA” are IBM S/360 assembly language operation codes and if you pick the wrong one it results in a nasty, hard to find bug in your program.)
I owned the only piece of assembly language code in my component; it was too performance critical to convert. Obviously, risky stuff. My first line manager, who wore socks with machine stitched Mickey Mouse images on them, told me they had scheduled a walkthru of my rewrite of it. I told him that I would discuss particular criticisms of my code but that I “would not be ground up”. They backed off and cancelled the walkthru; my [obviously both risky and product critical] code shipped unreviewed and I never heard any APARs (“buge”) from it. I was dead right, i.e., right and dead.
By the words “egoless programming”, back then (1978) I understood an attempt to make computer programmers have no egos, i.e., no souls, no sense of self or self-respect. I considered myself to be a zek (that’s what inmates of Joseph Stalin’s Gulag were called) in Cyberia.
So you can imagine what I was expecting when I Googled “egoless programming” and your 10 commandments came up. But what I found looks entirely reasonable and respectful even of low level computer programmers, not something to destroy their minds and souls. Criticize the code; educate the coder.
I don’t know if you know about “The great GOTO war” from that time (1978). They wanted to get rid of GOTOs because GOTOs could enable incompetent programmers to easily write unmaintainable code by branching into anywhere from anywhere at any time. I was on the losing side, like the Confederates in the Civil War. (As a COBOL trainee, I rewrote one such program; I replaced infuriating spaghetti code where you could not follow what it was doing, with clean table-driven code.)
Today I see more clearly than I did then: They were objectively correct that GOTOs were not good, but they were doing it in a Stalinist way and I balked at having my soul destroyed. Had they approached me respectfully and engaged with me as a peer… I hope I would have acceded to what the philosopher Jurgen Habermas calls “the unforced force of the better argument”. I was fighting against being a goose for foie gras. I was not really fighting for GOTOs: I was fighting for human dignity for people who had only gray plastic top, not fake wood top desks, i.e., for myself. (Had they made me an offer to become a warder, I might well have joined the enemy as staff officer, but they didn’t.)
There is a relevant book here: Philip Kraft, “Programmers and Managers: The Routinization of computer programming in The United States” (1977).
I would call what your 10 commandmants seem to me to say something not so easily interpreted by wounded veterans as soul murder. Something like “reflectively distanced programming”, i.e., where “we all – from the people with fake wood top desks to those with only gray plastic top desks – are all peers striving together to make the computer have as good a product as we can, with all of us supporting each other as equals. The computer and the program are both objects we use to achieve our cooperative goal, but all of us are the subjects, not some of us treating others of us as objects along with the computer.” Criticize the code, educate the coder, respect everyone.
Computer science is one thing. the labor of wage-slaves in a capitalist economy is another thing. I paid the bills writing code but only because I could not find a way to do that by being a humanist scholar, a failed philosopher and later an excommunicated psychoanalyst. I started programming keypunching my own drum cards; for fun, I once turned a big insurance company’s production IBM S370/158 into a simple adding machine from machine code I punched into cards which I IPLed from the card reader; as a systems programmer I did all sorts of stuff in key zero supervisor mode on big bank corporate computers; I loved both 360 assembly language and APL; I finally got PTSD from trying to make Angular 2 jump thru undocumanted hoops and failing to succeed at it. I could never find any employer who valued my wisdom, only use my manpower. Everybody wanted new hires who lusted to work in a fast-paced environment; I had seen haste make waste.
I hope you have learned something from one person’s experience in Cyberia back in 1978 with the term “egoless programming”. (Many years later I came to resent: “scrum”, ideological purification “criticism and self-criticism” meetings like in North Korea; “scrum” derives from the brutal British sport rugby)
Let me close with two things: (1) In IBM, in 1978, I once met a person who programmed APL for chip production applications in Purgatory (IBM’s Fishkill New York computer chip facility); he rewrote programs that ran for days and reduced run times to a few hours; he had been a delivery truck driver but they gave him a programmer aptitude test and he proved to be a programming genius or close to it – he came to work sometimes, wore jeans, and grew house plants in his basement. (2) There is a famous IBM poster: “How to Stuff a Wild Duck” (It’s on the internet). It shows a duck whose feathers are all the cliches about corporation conformity; Thomas Watson Jr says that every company needs its wild ducks and IBM knew how to take good care of its wild ducks. I, alas, became just a dead duck after "Quack!"ing for 19 years.
Thank you for reading. Your thoughts welcome: bradmcc@bmccedd.org (https://www.bmccedd.org)
2 Likes
These are amazing stories, thank you for sharing them with us! 
1 Like
I have lots of stories. For one, when I was a junior systems programmer in a big insurance company, walking back from lunch one day with the 2 sr sp’s, one of whom was obese, party crippled and looked mentally disabled but in reality was highly regarded by IBM Field Engineers, and the other, who had never seen a dentist in his life, The IBM sales rep and my employer’s VP of DP were walking a few steps behind us. IBM Sales Rep to VP loud enough for the 3 of us to easily overhear: “There go your bearded hippie freaks” (in fact, 2 were “rednecks” and I was a Yale graduate – none of us were in the love beads set although they did allow me to have a beard). I was young then. Today, If that IBM Sales Rep had done that, I would have called IBM Corporate and he would have been toast.
IBM again. Overheard walking down an aisle in “Armonk” (1986ish), one business planner to another, verbatim: “Fishkill is not coming in with the inventions on schedule.” Uh, huh.
2 Likes
Well, if you ever recall any more stories you’d like to share, feel free to share them here. As long as they’re family friendly 
1 Like
Yes, yes, Brad (@bradmcc), I found your stories interesting. Funny how many of the same situations you talked about are still happening. It’s like that in practically every industry.
I hope I won’t repeat myself here: My first programming job (1973, USF&G a very partician insurance company) I was a trainee and there were two systems programmers. The senior guy was in fact highly competent and well respected by IBM Field Engineers but he literally looked mentally retarded and people would give him short change when he bought something in a store (he was also legally blind and partly crippled). The other one had never seen a dentist in his life.
So there was the “moron”, the redneck and me from Yale and they did tolerate me to have my short scraggly beard (the other two were clean shaven). We were all 3 dressed properly in business attire. One day the three of us were walking back from lunch and the DP VP and our IBM Sales Rep were walking a few feet behind us. The IBM Sales Rep (Harris Jones was his name) said to our DP VP, quite loud enough for the 3 of us to hear: “There go your bearded hippie freaks”. Many years later I asked the senior guy if I had remembered correctly and he assured me I had.
One morning when I came in to work, the guy who had never seen a dentist was sitting at his desk already working, drinking CocaCola and popping M&M’s. I said to him: “Manley, you’re going to rot your brain!” He smiled through his rotting teeth and replied: “Nope! Never had none!” He got stuck converting DOS to OS (“DUO”) and years later became head of DP For Michigan Blue Cross and one night unexpectedly died in his sleep.
The senior systems programmer had a checkered career including [literally:] getting fired for doing too good a job at a big bank where he had risen to AVP. He finally crossed the Social Security finish line and took early retirement. The last I heard of him, a year ago, he had somehow become a Trumpie and, bedridden with serious back trouble, fantasied shooting it out at his front door to defend his rights against the Democrats in a new Civil War (He has guns and knows how to use them). He had been an incredible systems programmer – he used part of an old WWII bomb sight to read core dumps, and he had been also a really great manager (he led from the front, not from the rear).
Here’s another one: Another really great manager I had in a big bank. He has a sign on his desk:
We the unwilling, led by the unknowing.
Have done so much with so little for so long
That now we are qualified to do everything with nothing.
Needless to say, not the greatest place to work. He was so great a programmer he did not just report bugs to the manufacturer: He told them how to fix the bugs and they applied his fixes. His successor was rumored to carry a concealed pistol to work (1976ish) and I never asked.
2 Likes
So packing a pistol had nothing to with the manufacturer doing what he told them to do? 
1 Like
Maybe I wasn’t clear and I did not tell the whole story: The manager with the “Can do everything with nothing” sign on his desk, Harold Jones, was a Burroughs Midrange computer expert systems programmer. I was hired to do the IBM side of converting the bank’s big Burroughs system to IBM MVS. Harold asked to go back to being a non-manager systems programmer because, he said: “Somebody’s going to get ground up in this conversion and I don’t want it to be me.” Then they hired a new manager of systems programming to replace Harold. The new guy, whose name I forget, is the man who supposedly carried the concealed pistol to work in the bank (this was before 911, right? And he may have had reason to be concerned for his safety outside the office). Now: The new guy lived over 40 miles away and had a big commute. The bank was in Baltimore Maryland. I used to ask the new guy: “Have you found you dream row house in Highlandtown?” Highlandtown was a “bad neighborhood” where bank managers did not reside; “row houses” are not McMansions.
Back to Harold Jones. He was a real “redneck” (these were the end times for the Data Processing “Wild West”). One Easter Sunday morning he was working in the datacenter and a black employee stopped by to show off the place to his girlfriend. Harold spontaneously exclaimed “A chocolate Easter egg!” The guy took it in good humor. Times have changed, yes? The second shift data center manager was an old army man who had quit after 19 years (you get a pension at 20). He came to regret this. He got so frustrated that he told his manager: “If you tell me to dig a hole, I dig a hole. If you tell me to fill it up again, I fil it up again. Anything you want, SIR!” He got what I called a “remotion” to 3rd shift manger.
Meanwhile, back in the check sorting department (we had a big row of check sorters then because credit cards were not yet hegemonies), a number of the low level workers got fired for smoking marijuana on the job. Department of humor: one morning I came to work and a lady was literally standing on a table in the cafeteria and shrieking because there was a mouse loose in the cafeteria …
2 Likes
Different job: IBM Research. We got to choose our own computer user id. I chose: MICE@yktvmv.
1 Like
My comment above was meant as a joke. 
But I’m glad you added to the story which clarified things.
Whenever an old co-worker (and now neighbor) and I talked about some of the stuff that went on when we worked together years ago, I always had a lot more to tell him than he could tell me. He left the job after 10 years… me 20 years. He would always finish our conversation with, “People would have to believe what you say because no one can make up this kind of $#it” - and then laugh.
There used to be two older “gentlemen” who used to talk about their time spent during WWII. They were sitting together having lunch and at the next table I sat with another employee. One guy was telling the other how he didn’t know how to swim and was terrified of the ship ride across the ocean. He said he was sea sick most of the time. The other guy - and I’m trying to spell these words as they were pronounced - asks him if he saw any daltons. The other replies, "No, but I saw some porkisis. The guy sitting with me choked on his sandwich as he burst out in laughter. I had to perform the Heimlich maneuver on him. 
Those two guys always gave us a good laugh.
1 Like
I just finished reading the classic - The Psychology of Computer Programming, by Gerald Weinberg, only to notice that the Ten Commandments were never mentioned! While this book introduced the concept of egoless programming, attributing the Ten Commandments to it is a case of attribution drift in software engineering folklore.
It’s also proving to be an impossible task to find out the actual source. I suspect that whoever came up with this list simply (mis)attributed it to Weinberg, even though the book itself contains no mention of it.
Ah, I see that somebody else has already commented about this, way back in 2016. My suggestion - how about you add a small note in your article itself about the misattribution?
2 Likes
Yeah, I kinda ran out of steam on this one. Very hard to find the original source, more researchers welcome!
The Internet Archive 
has a copy of the book, I updated the post to reference that, borrowed it and here is a search for “egoless” across the actual text:
Page 56
EGOLESS PROGRAMMING
Page 58
This incident is not an isolated case, and this group is not unique. Why, then, are such groups not more conspicuous? Why is the practice of egoless programming” not more widespread? A number of factors might be invoked to account for the impression that such groups are rare. First of all, many of the successful software firms are based on this type of interaction, and though they will admit to it under direct questioning, they often regard this knowledge as valuable proprietary information. Secondly, groups working in this way tend to be remarkably satisfied and stable, so that the programmers we find wandering from installation to installation are not likely to have come from such a group. Moreover, these gypsy programmers—to achieve a constantly escalating salary range—must encourage the myth that the best programming is the product of genius, and nothing else.
Page 58
An interesting anecdote—which we mentioned briefly in the chapter on methods—can be told about one of our studies that tried to assess the difference in programming results obtained when different programmers were given slightly different impressions of what they were to achieve— efficient coding or quick completion. As usual, individual subjects were employed, but one of these subjects—they were all students on a special three-month course—happened to come from a group that practiced egoless programming. At a certain point, he came to me and said that he
Page 59
As a sidelight to this incident, it should be noted that this programmer’s work seemed to the evaluators to be better organized and better executed than the other four programmers working on the same problem. In discussing this question with him, he raised the point that he had worked throughout as he always did in his own group—always with an eye to making the program clear and understandable to the person or people who would ultimately have to read it. This insight indicates that all the advantages of egoless programming are not confined to the detection of errors, though that was perhaps the earliest and strongest motivation for adopting the technique. In fact, it might be useful to examine our four factors in good programming in the light of what effect this method would have on them. :
Page 60
In the same way that an installation fixates on a programming language, it can establish a general social environment which either encourages or discourages egoless programming. When a new programmer
Page 61
Sometimes the group may have to maintain its philosophy in the face of a larger threat than the introduction of a new member or two. Adherents of the egoless programming philosophy are frequently subjected to threatening moves on the part of managers from higher levels in their organization. Managers tend to select themselves from the ‘‘aggressive’”’ component of society and have difficulty appreciating the fact that other people do not completely share their goals of money and prestige. They are especially at a loss to understand the smooth functioning of a programming group based on mutual respect for individual talent and cooperation in the common cause. Instead, they tend to view people as working for money or under threat—as they themselves do.
Page 63
A case in point was Jim A., who was brought onto a newly forming project in Chicago from a programming center in New York. The group to which he was assigned was headed by two people who had been firmly brought up in the egoless programming tradition and who were determined to propagate that tradition in this project. The group consisted of these two, Jim, and four trainees. On the first day the group assembled, the group leaders began the indoctrination of the others into their method of working. It was decided at the beginning that each of the group members was to have the signature of one of the other members on his run request before going on the computer with any job. By this slightly formal method, they hoped to ensure that the group members would get in the habit of doing what they would come to do spontaneously later on.
Page 65
. What would you have to do to introduce egoless programming into
Page n103
The concept of “egoless programming,” first described in this chapter, is probably the most cited, most misunderstood, and most denied of all concepts expressed in the original book. I’ve often wondered if | could have written this section with more persuasive power. Perhaps there would have been no controversy had | used the term “less-ego programming.” Perhaps | needed more examples, or better examples. Perhaps | needed more experimental evidence.
Page n103
Writing about egoless programming, | said, “Another reason these methods are not better known is that nobody has ever experimented on the difference in quality of work produced by this method and the method of isolated individual programmers” (p. 58). Here’s an area where twenty-five years have corrected the situation, and there is now no shortage of evidence that, for example, technical reviews (inspections or other forms) lead to more reliable code produced more cheaply and consistently.2 And, indeed, more software organizations
Page 72
These structures, of course, are idealizations. They do not reflect, for example, whatever inner structure comes about because of the general programming philosophy of the larger group to which these team members belong. The organization in Figure 5-1 might in practice be far less hierarchical if the group practices egoless programming; while the team in Figure 5-2 might be far less egalitarian if its members did not. Status of members of a team evolves in a manner influenced by a number of factors, and the factor of who criticizes the work of whom is one of the strongest. Thus, if egoless programming is used, everyone in the group will have the opportunity to examine the work of everyone else at some time, thereby tending to prevent the establishment of strong hierarchy.
Page 72
Suppressed feelings by a team member about the inferiority of his assignment can be surprisingly damaging to a team effort. Egoless programming tends to moderate such feelings, since each programmer
Page 94
Hopefully, Mills will publish his ideas on Chief Programmer Teams in the general literature, so they can be compared, say, with the concept of egoless programming and also subject to experimental and observational tests. Briefly, the Chief Programmer Team is patterned after a ‘‘surgical team,” with the master programmer replacing the master surgeon and surrounded and supported by a Backup Programmer, a Programming Librarian, and possibly additional programmers, analysts, technical writers, technicians, or other specialists. Mills claims that such an organization ‘permits the application of new management standards and new technical Standards to programming projects,” but one wonders at the validity of the analogy to surgery, which is acknowledged to be one of the most backward specialties in a backward (technologically) field. Also, anyone who has known a few surgeons personally may wonder about how great a social contribution such an organization would be—it may be fine for those who fancy themselves Chief Programmers, but what about the rest of the workers?
Page 98
A similar case with a different outcome should be instructive as an illustration of the concept of stability through constant change. Henry F. played a similar role to Mark S. in a project connected with the space effort. He had designed the control program and had been made team leader of a somewhat larger and better qualified team. As he began to tire of the implementation work, he filled his time by training his two best qualified team members, Mary M. and Sid B., so that they would know as much about the system as he did. The training was made simpler by the democratic organization of the team and their practice of egoless programming, but it was not encouraged by higher management.
Page 108
We have no way of measuring whether or not this improved social climate led to better or worse work between these two groups. However, we do know through our experiences with egoless programming that there is no particular reason why your friend cannot also be your sternest critic. We could certainly use controlled experiments on this question. In the meantime, it probably is a good idea for a project manager not to foster conflict between groups whose work brings them into some sort of natural conflict.
Page 136
ming work. Thus, a project that can divide the effort not into programs but into types of work might realize gains in productivity of this magnitude. Notice that this is precisely what happens when egoless programming is practiced; and as long as programmers “own” programs rather than, possibly, “owning” programming stages, we are not going to realize these potential gains.
Page 146
As usual, all other things are never really equal. Such personality traits as emotional stability or instability will affect how well a person can tolerate being in any paradoxical position for an extended period. Because the period of time is important, a manager can, by changing work assignments more frequently, relax the stringent personality requirements that might otherwise be necessary for the job of product test programmer. This type of alternation of jobs is accomplished automatically through egoless programming, for no person is subjected to unrelenting assault on his particular personality—the type of assault that forces people into “attempts at adaptation.”
Page 147
Through egoless programming, then, we sacrifice the possibility of having each person always in the job for which his personality best suits him, yielding, in this way, some potential efficiency for security and stability. Moreover, the full potential for efficiency may not be lost, since we are not likely to have had the perfect mix of personalities in the first place. Then, too, “‘wearing the other man’s moccasins” has always been a good way to develop the personality trait of tolerance.
Page 268
What such a system does—with suitable provision for updating as changes are introduced—is to take us back closer to the time when the documentation was the programmer himself. In a small shop, on a small program, little attention was paid to explicit documentation, for it was always easier to go to the originator to get the answer. After all, you probably had to ask him in order to find the documentation. In fact, in such a situation today, this is probably the best method. Any programmer knows a lot more about his program than he will ever be able to put in his documentation, or than anyone would be able to find as needed even if it had been put in. The major problem with this method is when a programmer leaves the shop, but if egoless programming is practiced— and if the management is not so bad that all the programmers leave at once—this problem is minimized.
2 Likes