Egoless Programming

Colleague One: I erased the new function you wrote today.

Colleague Two: But I wanted to erase it!

It is amazing what one can accomplish

if one does not care who gets the credit.

A concept introduced by Gerald Weinberg in The Psychology Of Computer Programming. The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism. Rather, they should do their best to treat their designs & implementations as objects independent of themselves, and to view criticism dispassionately on its merits. It's a spiritual discipline that we all fall short of, but that's worth attempting.

How can one convince other developers that egos aren't required? Simply leaving names out of source files doesn't seem to suffice, and it seems interesting that on an Egoless Programming page, almost all contributions are signed... Well, there is ego and then there is ego. The ego in Egoless Programming suggests we could do with less of was that part that says "I'm better than you", not the part that says "I did this, including the mistakes."

Although Software Without Ego taken to the extreme is generally recognized as being unworkable, it is useful as a check against an extreme in the other direction, Heroic Programming. There is a balance that must be struck between complete deference to the customer and team, and their total exclusion.

Egoless-ness seems to be an essential part of the Wiki Nature. (See, for example, the invitation at the bottom of this page. Ward may have invented it; lots of us use it.)

Clarification: Ego is Identity; Self-Orientation is the Poison

One common misunderstanding about Egoless Programming is that it means that the programmer participates without opinion or in some disinterested fashion. While reasonable, this is a misunderstanding. Ego is identity. It's when the programmer merges her identity with the program, and clings to it, that causes the problems we are aiming to avoid when we say "do egoless programming." It's ego-less, not ego-free programming.

Ego itself is a useful tool. It gives human beings a point of reference separate from the flow of existence and allows us to gather our experience and synthesize mental models. Our mental models allow us to conceive of manipulations of the world before we enact them. It's this ability to play with creations first in our minds (which is relatively cheap) before we construct them in the world (sometimes to great expense) that makes us so potent. To the degree that our mental models are accurate, our planned manipulations will actually work when we enact them. When these manipulations harmonize with the essence of what's going on, they tend to work well with few unintended side effects. When manipulations are ill-conceived (mostly because key facts are missed or ignored), they can be quite destructive. Ego, the seat of this capability, is a potent tool.

Also, ego can accumulate gumption (i.e. we develop affinity for a certain outcome) and thus motivate us to take on endeavors.

The real trouble is not pride of a job well done, but self-orientation. As David H. Maister makes plain in his book "The Trusted Advisor", trust is thwarted in heavy fashion by self-orientation. When the self becomes the focus (when one becomes defensive, it is the self being defended) this tears away at the possibility of collaboration. You need to be able to trust each other to collaborate effectively. It's this dampening effect on collaboration in a group venture that makes Ego-filled programming a problem.

In general, to the extent that a teammate has not taken responsibility for their ego, he subtracts from the team's ability to gel and function fully. If instead, he bridles his ego and aims to participate in something greater than himself (note that this includes himself), he is melding well and makes it more likely for the group to realize the gestalt effect.

Teams that work well together are far more productive. They get more done in less time and at a lower cost. There is significant business value, then, in cultivating the conditions for collaboration. This is the business driver for championing true Egoless Programming.

Why program egoless?

A strong but uninformed and childlike ego can be a scary sight and coupled with undeserved power, can be devastating. Take the case of the Hyper Sensitive Code Machine - an individual highly sensitive to criticism, able to produce quantities of code, loves to work in isolation, AND very poor communication skills. In relation to Extreme Programming, code is the variable optimized for - everything else, testing, review, continuous integration, pair programming (to say the least), personal communication, etc, is compromised. Hyper Sensitive Code Machines:

hesitate to submit to peer review

do not cope well with criticism

produce lots of code, littered with errors

negatively affect personal and team dynamics

have to be reminded to test

confine themselves to their personal cube or office

The problem with egos is often not the absolute size of the egos but their relative size of egos. Where someone with a large ego crushes someone with a smaller ego, the difference in sizes can stop ideas from flowing. One can still care very deeply about a project, problem domain, code quality, etcetera and yet not feel attacked personally when an aspect of the thing is called into question.

But a strong ego is essential to both creativity and resting soundly on competence in a chosen profession. We validate ourselves by our "pride" in being both creative and competent. The danger to our egos in a group setting is that our personal convictions about how creative or competent we are may be revealed to, and proven false by, the group.

Therefore, some degree of personal sacrifice from strong players is essential to the healthy functioning and ultimate success of a group with a mission. The weaker players are mostly there to observe, learn, and strengthen their own egos as they become more competent. Hopefully, this facilitates future opportunities for their competence-fortified creativity to be offered and used in a future group.

Criticism

Dion Hinchcliffe suggests Egoless Programming doesn't work because it assumes that everyone else is right and does not permit the self-recognition of better ideas. The basic idea that a designer, analyst, programmer should try to exclude all aspects of the ego and focus in a "pure" manner on the problems, requirements, and ideas of others seems impractical. Besides we all have egos that we must live with. (In contrast, another interpretation of Egoless Programming suggests that someone else may be right and explicitly permits [demands?] the recognition of somebody else's better ideas.)

Some people find Egoless Programming hard to make compatible with individual Code Ownership (Cope's going to jump all over me for this) but an essential part of team Code Ownership.

Others like the concept but strongly dislike the name. Not getting all huffy and irrational when someone suggests that your code might be changeable for the better doesn't mean you have no ego, no sense of self, no "I". It means you have a nice healthy ego / self / I that can take constructive criticism and use it for good. Some of the best code is written by people who strongly care about, even identify with, their code (so hardly "egoless"); and because they care about it, they want to improve it, and so they react correctly to people pointing out flaws in it. Would anyone call Larry Wall "egoless"? *8)

Some believe that Software Without Ego is a manifestation of the beliefs inherent in anti-individualist philosophy which usually comes in the form of bromides like "teamwork is more important than individual contribution" and "one person can't (or shouldn't) make a difference". The results of such thinking are usually referred to as "Design By Committee", which now has a universally negative connotation for obvious reasons.

Betsy Hanes Perry adds that it isn't that practitioners are egoless; it's that pretending to be egoless has good consequences. What you feel when somebody finds a critical bug is entirely your own affair; what you say affects the team. Most successful writing workshops practice a similar discipline.

Finally, some people wonder why Egoless Programming has felt the problem lies with the recipient of criticism rather than those providing the criticism. Sometimes those doing the criticism that have too much ego.

Indeed. If we truly want the coder to be egoless and accept constructive criticism, we need to make sure we are providing constructive criticism, and not puffing our own egos by tearing down the coder.

Howto program without an ego

The deal is this: when I say something to you about your program, you should listen - listen well, so that you really hear me. If you are all involved in getting insulted because I don't see how glorious you and your code are, we won't be productive.

The Veil Of Ignorance tells me that if I expect this of you, you have a right to expect it of me. I don't have to believe you, or act on what you say. I have to treat your questions and ideas as if they were valid, and consider them with the same acceptance that I consider my own. When they're in my brain clearly, we can discuss the alternatives dispassionately and decide what's best.

It turns out that if I do that, I do better. I have been repeatedly surprised in my role as Coach on C3 that even the newest newbie quite often suggests a course of action that is better than what I had in mind. In fact, now that I think of it, I have actually seen Kent Beck benefit ... :)

It's a more daunting challenge than you might realize. How many programming discussions have you heard or been a part of where the programmers refer to the code in first person: "so when I get a message from you, I have to update my X widget and then send Y message to you...". The pure convenience of using short, personal pronouns in place of naming the responsible programs, objects, or methods is a difficult habit to break. Take a few days and you'll see that this behavior is quite prevalent.

In "The Timeless Way of Building", Christopher Alexander relates how "egoless" is part of "The Kernel of the Way". The key to "egoless" seems to be doing just exactly what the problem or situation requires, no more, and no less. Letting the solution emerge from the problem, rather than imposing a solution upon the problem.

Arrogant Egoless Programming

Programming "egoless" opens the design to improvement from inception, but that doesn't mean you should be without any ego. Arrogance is essential. You must believe the design you have chosen to follow from the first understanding of the problem is capable of evolving into something which will complement or encapsulate all of the subtle interactions in the implementation.

How can we stop the arrogance of ego from blinding us to what is often obvious (in hindsight)? Put it in perspective by accepting that there is much more to know than I already know. This perspective does not remove ego from the design environment, but it does remove the negative impact of ego by encouraging me to consider all resources, regardless of source. It is amazing how often the really useful solutions and concepts come from people in the least likely roles.

Is it worth being careful about what is and is not a "fact"?

Some things are facts, when dealing with actual code. For example, you could write a procedure that takes the average of two numbers. Upon inspection, I discover that it really just adds them together and you apparently forgot to divide by two. I'd consider it to be a fact that the code is broken.

However, when it comes to more abstract concepts, I tend to have severe nihilistic leanings, so it's hard for me to see the line other people draw between "fact" and "opinion". According to the above, we should act differently when we talk about opinions versus facts.

I'll start two lists that have my best guesses. Everyone can edit them until we have a satisfactory distinction between fact and opinion.

Examples of facts:

I inspected your code in a debugger and saw an integer overflow, which led to an out-of-bounds array index, which caused the program to crash.

Fortran can be more easily optimized by modern compilers than C.

I measured the performance of these two implementations of XYZ, and implementation A is 20% faster.

Bit-shifting is faster than division on most processors.

Examples of opinions:

Your program is using 16-bit integers, which are overflowing. You need to increase the size to 32-bits.

Fortran is better at numerical computations than C.

Since implementation A is faster, we should use it.

Bit-shifting is a Premature Optimization.

General guidelines

Don't simply declare your decision. In most cases, things shouldn't be a decision from any one person. There should be a discussion.

Facilitate and encourage discussion by encouraging all to contribute to decisions.

Don't use put-downs, e.g. "That was the buggiest code I've ever seen." Be clinical when it comes to code that isn't yours. Better: "There were a few bugs."

Constantly search for better solutions. Openly discuss innovative solutions. See if they apply elsewhere. Ignore errors - note them to be fixed, but ignore them. They are not part of design (unless you are building an Exception Manager).

Don't assume that someone hasn't already put plenty of thought into something. "Now that we're done with this, let's go back and pick some decent colors for the web page."

Acknowledge individual contribution [unless this is very strongly frowned upon in the culture in question, someone I once worked with cited his doing this as one of his biggest faux pas during a period working in Japan - Jon Hanna].

Don't state facts. State opinions, because that is what they really are. Bad: "Nobody puts binary data in a database. It just doesn't make any sense." Better: "I've never had a good reason to put binary data in a database. I've never seen the benefits of it."

DO state facts as facts - this design exposes security holes; this other one has several specific advantages; DO state opinions as opinions rather than facts - the design that corrects that problem seems better to me.

Examples

Some excellent examples of what can be gained from Egoless Programming:

Don Knuth's essay "Errors of TeX" on all the bugs he found in TeX (cited in Sources Of Bugs) It can be downloaded (tex.loria.fr ).

Brooks's 20-year revision of the Mythical Man Month, which has a chapter on what he got wrong.

Bertrand Meyer advocates "egoful design with egoless expression" (Object Oriented Software Construction 2, p878). He seems to mean that Coding Standards are good but creativity is otherwise desirable.

Counter Point: Ego Motivates

Humans are fed by ego. If you don't feed their ego, they lose interest. It might be more efficient on paper to take ego out of it, but we humans start to feel like grey automatons in a clinical nightmare without ego. We like to play intellectual one-upmanship and turn programming into a sport. How To Win Friends And Influence People shows one how to motivate by stroking others' egos. (It does not use the term "ego" for the most part, but it is implied.)

I think this is a really good point and should be considered by all developers at one stage or another. Ego really can drive good programming. I prefer caling it 'pride' or even 'perfectionism' rather than 'ego' though because ego can refer to other concepts that are counter-productive (such as the examples on this well written page). One example off the top of my head is the type of computer ethusiast who loves to talk technical to friends and relatives in order to sound smart.

Unfortunately, pride / ego can get in the way of good team relations. When you try hard to think of good symbol names, create nicely decomposed code and follow good coding practices in general, it can hurt to see your creation get mixed in with piles of uncommented, 200 page long classes. Kind of like taking someone's carefully made craftwork, making some 'special changes' to the design, then handing it back to them to work on before selling it to a customer.

Category Criticism

See original on c2.com