Coder Failures: July 2008 Archives

I'm sure that, by now, you've all heard of Egoless Programming.  If you've been under a rock for...ever (or not reading coding blogs, in which case, welcome to the land of the enlightened.  Try Coding Horror, it kicks my blog's ass) Egoless Programming is defined by the following Ten Commandments (Which is on Jeff Atwood's list of the better programming 'Top Ten' lists out there.)

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.

3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.

4. Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

5. 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.

6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

7. 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.

8. 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.

9. 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.

10. 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.

It's a good list.  There's lots of stuff in there that's worthwhile to read, understand, and do.

But I wonder...is it right to call this 'Egoless'?  I don't think so.

Programmers, Developers, System Engineers, Code Monkeys, no matter what you call us, we are builders.  We are shapers.  We are doers.  We design and develop things that no one has ever seen.  We are creative and constructive.  Should we push all of that aside in the name of "Egoless Programming"?

No.

We code.  If you're reading this, it's likely because you like to code.  Our code is not ourselves, yet it IS a part of us.  I'm sure many of you, like myself, cherish the difficult problems.  When we are coding, we eat, breathe, drink, and dream our code.  For a brief time, when we are working on our challenges, they are a part of us, like our arms or legs or technical gadgets.

When we are done, we proudly show it, saying, "Look what I have wrought!"  This is the definition of ego-filled coding...yet is it truly contrary to the 'Commandments' in the list above?

1. Understand and accept that you will make mistakes. This is not at all contradictory.  When we code, we practice our art.  The very fact that it is referred to as 'practice' implies room for improvement.  (As an aside, this is why I dislike doctors.  I'd rather they get it right the first time, since it's REALLY tough to recompile our DNA)
   

2. You are not your code. No, we aren't our code.  But our code IS part of us.  When a problem is found and we discover a way to improve our code, we should be overjoyed!
   

3. No matter how much "karate" you know, someone else will always know more. This is not contrary at all!  Any programmer worth his salt will LOVE to learn new tricks.

4. Don't rewrite code without consultation. Definately true.  Writers have first readers, artists have private showings, coders have design reviews.  The end result is the same: an improved final product.  This is not egoless, as it is the very CORE of ego to show others what you have done.
   

5. Treat people who know less than you with respect, deference, and patience. Teaching others what we know is almost as rewarding as putting it into practice ourselves.  And being respectful is simple good manners.  'Polite' does not mean 'Egoless'.
   

6. The only constant in the world is change. "Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought."  I'm quoting the explanation here, because it says it all: This is a challenge.  Conquer it.  How is this not 'ego'?
   

7. The only true authority stems from knowledge, not from position. "If you know more than someone above you, you have the true authority."  Wow...that's not just ego, that's the BAD SIDE of ego.
   

8. Fight for what you believe, but gracefully accept defeat. Ego should not say, "I am always right," ego should say, "I am often right, but I am willing to learn."  Try other ways.  More karate is better.
   

9. Don't be "the guy in the room." The lone guy in the room has no ego.  He cannot compare his creations with others, he cannot improve, and he cannot share his creations.  One who truly has ego will share, collaborate, and (in the process) learn.
   

10. Critique code instead of people -- be kind to the coder, not to the code. This, again, is not so much 'ego' as 'polite'.  If someone asks if I like their hairstyle and I don't, I say, "No, I prefered it the other way," not, "You're a terrible person, DIE DIE DIE."

In short, programming should NOT be egoless, or it will be lifeless.  Coding should, however, balance ego with humility and an eagerness for self-improvement.