Epic Fail

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.

I'm sure some of you have come across this before.  It is yet another ranking system for programmers.

Let's have a look at some of the rankings:

data structures:
Level 0:	Doesn't know the difference between Array and LinkedList
Level 1:	Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks
Level 2:	Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc.
Level 3:	Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc.

Intersting, no?

For the most part, I agree with this list.  In general, as you progress up the list from level 0 (called 'n^2') to level 3 (called 'log(n)') you tend to move upwards in programming skill.

The problem I have with this matrix, what I consider its failure, is its lack of context.  Yes, it's great to know that if you understand the concept of Concurrent programming languages, you're a level 3 programmer, but does anyone reading this list know what that means?

I'll tell you what it means: it means you understand Concurrent programming languages.  Nothing more, nothing less.  Yet to anyone reading this chart, you'd think we programmers get together and rank ourselves based on this.  Admittedly, I'm new to the field of software engineering, but I've yet to see anyone who openly considered themselves better than anyone else because they are a level 3 programmer on some chart.

Even worse, this chart (like almost any way to lump people together in an arbitrary manner) is open to misuse and misapplication.  Suppose a hiring manager got their hands on this, and decided that they don't just need any programmer for their new app, they need a LEVEL 3 programmer.

They work for months to find him, weeding out hundreds of candidates who just don't measure up.  Sure, they might have ten years of professional experience and have written their own frameworks, but their blog is just a LINK BLOG.  Such a fine gentleman is obviously NOT a level 3 programmer.

Once they find this elusive beast, the level 3 programmer, they hire him, and damn the cost!  Two weeks later, he's bored out of his mind with adding buttons to the dinky little windows app to count widgets in a warehouse, and is wondering why he ever took the job.

A chart like this relies on two things to be properly used: a common set of standards with roughly equal weight, and the knowledge of a viewer of what the levels actually mean.

In my example above, the company didn't need a level 3 programmer, as defined by this chart.  They probably only needed a level 1 or maybe a level 2.  But how were they supposed to know?  No context is given.  There's nothing here that says, "a level 1 programmer is likely competent and capable of learning, and can handle most common tasks"  or "a level 0 programmer is still learning, and could improve if given training and time".  It's a hard, fast, limit: Quality X indicates Ability level Y.

In addition, there is a gross disparity between what makes up the differences in levels.  Take for example, scripting.  At level 1, you can make batch files and use basic tools.  At level 2 you use a large number of scripting languages.  At level 3, you have "written and published reusable code".  This is one of the less useful metrics I've seen in recent times.  The difference between levels 2 and 3 is minor and not even related to the topic!  Publishing, in and of itself, means nothing.  If I write a script that automates building and deploying a widget, or even generalize it to build and deploy any widget given some parameters, what difference does it make if I publish the code?  How does it make a difference to my ability to script if I have posted my scripts for reuse?  How does it limit my ability if I don't?

Consider the database section of the matrix, levels 2 and 3.

Level2	Able to design good and normalized database schemas keeping in mind the queries that'll have to be run, proficient in use of views, stored procedures, triggers and user defined types. Knows difference between clustered and non-clustered indexes. Proficient in use of ORM tools.
Level 3	Can do basic database administration, performance optimization, index optimization, write advanced select queries, able to replace cursor usage with relational sql, understands how data is stored internally, understands how indexes are stored internally, understands how databases can be mirrored, replicated etc. Understands how the two phase commit works.

So...the ability to DESIGN a normalized database schema is a lesser ability than basic administration?  Understanding basic concepts of databases and their administration is (IMHO) much simpler than designing a good database structure.  Knowing how a two-phase commit works is far less difficult than being proficient in ORM.

The concepts of database design, database usage, and database administration are complex and disparate...yet here they are all lumped together, seemingly in no order.

And don't even get me started about the 'Years of Experience' myth.  Coding Horror has done it.  Far better than I could.

I could go on, but I think I've made my point.  Pigeonholing people into arbitrary categories is a substitute for understanding.

In order to truly begin any blog, it is required (by the WWW Council of Incompetent Robot Elders, I'm told) to begin with an introduction.

This is such an introduction.  If this is the only post ever made on this blog, the name will be true.

My name is Jeff Chambers.  I am a Computer Scientist, a developer, a code monkey, a hacker, a hacker wannabe, a web designer, a husband, a father, a genius, a fool, a lover, a dreamer, a geek, and a good person.  Depending on whom you ask, of course.

Background: I graduated from Northern Kentucky University in 2006, with a Bachelor of Computer Science.  I'm employed (quite happily, in fact) married, a father, and (now) a blogger.

About this blog: This blog is mainly a place where I will muse on various forms of failure.  Many, I hope, will be development or design related, though this is not necessarily going to be true of everything I post here.

My opinion is that failure is the greatest motivator possible.  I know that, for myself, having failed once makes me more determined to succeed in the future.  I hope it is the same for everyone else.  If the world is largely composed of people for whom a single setback will destroy their desire to persevere, the future is bleak indeed.

I consider this blog an attempt to provide examples of failure (my own and that of others) that other people can learn from.

If you're still reading this, consider that a failure.  You should be doing something more productive than reading a relatively pointless 'About Me' post on a blog that MAY someday have 7 readers.