Egoless programming

On one day as I was preparing a presentation about code review for this particular team, I found the answers for my questions in a book first published in 1971. In 1971! In “The Psychology of Computer Programming” written by Gerald M. Weinberg I read about the concept of egoless programming and I not only found the root cause of my problem, but also the solution.

Dangers of ego in programming

First of all let’s make it clear why ego is dangerous in programming. We probably all have a project or a particular program we are very attached to. We polish it, raise it and improve it day by day. It is almost like a relationship. The program becomes an extension of ourselves. However, such an attachment of a programmer to the program can have serious consequences for his self-image. When there is a bug in the program, the programmer would have to reason like this: This program is defective. This program is part of me. I am defective. However, such a harsh self-judgement is seldom conducted, which leads us to the theory of cognitive dissonance.

Cognitive dissonance

Cognitive dissonance is a mental discomfort that is triggered by a situation in which a belief of a person clashes with new evidence perceived by that person. Since dissonance is an uncomfortable and unstable state for human beings it must be quickly resolved in one way or another. Most often it is resolved by actively ignoring or denying information that conflicts with existing beliefs.

Think for example of a men who purchased an expensive car. If the man who has just now purchased a BMW is given a bunch of auto advertisements to read, he spends the majority of his time by reading about BMW. If it was an Audi he purchased, then the Audi ads would capture his attention. He is ignoring the information that might create cognitive dissonance. If he purchased a BMW he would not want to find out that Audi is the better car. The best way to do that is to avoid reading Audi ads.

Now, in the case of programming when a programmer sees his program as an extension of his own ego, he is not going to try to find all the errors in that program. He would rather react to a reported bug with “The imported data is defective”, “The user did something wrong”, “Maybe the last commit of my colleague broke it”, but not with the sentence “I goofed again”.

And in case of review ego can be fatal. If someone thinks of a found bug as an attack on his own person, he starts to defend himself either by ignoring the fact that there is a bug or by fighting back. I found myself in exactly this situation and clearly fighting back would lead to a never ending word-fencing. Instead, the problem of ego must be overcome by restructuring the social environment and the value systems of the programmers in that environment.

10 commandments of egoless programming

1. The topic of egoless programming was and is still discussed heavily and one can interpret and adapt it in many different ways. In 2001 Lamont Adams published his interpretation, which resulted in the 10 commandments of egoless programming. (The original post from Lamont Adams can be found here.) While you will not find the following ten points in the book, I think it is the best way to explain what egoless programming is about and how it can be achieved.
2. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, mistakes are rarely fatal in our industry, so we can learn, laugh, and move on.
3. You are not your code. Remember, the entire point of a review is to find problems, and problems will be found. Don’t take it personally when a problem is uncovered.
4. No matter how much karate you know, someone else will always know more. There will always be people who know more than you. Such an individual can teach you some new moves if you ask. Seek and accept input from others, even (if not especially) when you think it’s not needed.
5. Don’t rewrite other programmers’ code. There’s a fine line between fixing code and rewriting code. The former implies that a bug or other functionality problem exists and needs to be fixed. The latter, however, refers to changes made to code for the sake of style. Know the difference, and pursue stylistic changes within the scope of a code review, not as a lone enforcer.
6. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
7. The only constant in the world is change. This one is my personal favourite. It means to be open to any change and accept it with a smile. Look at each change as a new challenge, not as some serious inconvenience to be fought.
8. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect — so if you want respect in an egoless environment, cultivate knowledge.
9. Fight for what you believe but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
10. Don’t be “the guy in the room”. Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
11. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc. Note: This point does not appear in the original post and it is unknown who was the first adding it to the list.

The other side of the coin

In order to truly understand the concept of egoless programming and to be able to decide whether your team or organization needs it and how you are going to establish it, it is important to have a glance at the other side of the coin, too. Think about the dangers if everyone assumes that everyone else is right and does not permit the self-recognition of better ideas. Discuss the problem of code ownership and do not forget about the counter point: ego motivates. Do not get on the hype train too fast and adapt egoless programming to your own needs. Do not exaggerate, but keep a balance between healthy competition and egoless team-work.