The concept of egoless programming, as described by Johanna Rothman:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/egoless-programming-you-are-not-your-job.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/egoless-programming-you-are-not-your-job.html
I’ve been involved in all stages of software development for more than 15 years. While it’s true that one consistant theme that differentiates success from failure is feedback. But another one is balance.
I believe that it’s best to hear all criticism and consider the source and parse it very carefully. If the path to better software is clear, take it.
When no light shines into a project it does have a tendency to become unintelligible. But when too much shines in, nobody agrees where the curly braces go.
My most recent ex-manager (I left, he’s still there) had, as so many do, the whole thing backwards. When we found a bug, he wanted to know whose “fault” it was. When I suggested that the (almost always lone) person who had written a program should be the last one considered to apply a change or fix, so that we spread the knowledge around the team, he rejected the suggestion on the grounds of inefficiency.
But when I pointed out that the code of a colleague (who was away on holiday when a change came up) had rocketed into my personal top ten of all-time worst programming efforts, he rallied round the incompetent - who, to be fair, caused very little trouble asking questions, making suggestions and other such disruptive behaviour - asserting that we were “all one team” and should support each other. Duh. I don’t work there any more.
Why am I unloading on the manager, apart from the obvious need to vent? Well, most of the - generally extremely competent - team had at various times asked to be allowed to conduct peer code reviews for pretty much the reasons in the Rothman quote. (I told you it was a good team). Identifying and fixing problems early was considered unnecessary… And don’t get me started on the lack of retrospectives.
There’s a paper (I’ll try to find it) that reports the findings of a study on the correlation between individuals’ assessments of their own competence and others’ assessments. It transpired, fairly obviously if one thinks about it, that the lowest quartile thought they were much better at their jobs than anyone else did, while the best actually discounted their abilities slightly. Which is pretty nasty, in the first case at least, because the implication is that most of the least competent idon’t think they need to improve/i. And if that isn’t a recipe for failure I don’t know what is.
The ideal situation, which is quite hard to achieve, especially for inexperienced programmers, is that you are full of ego and pride when writing the code, but egoless when it’s being (re)viewed by someone else.
When writing the code, I always try keep into the back of my head, that the code I am writing might very well be (re)viewed, at some point, by someone else. How will that person perceive my code? If you have pride in your code, you will try to do your best, to make sure that it will withstand any inspection. It has to be : readable, orthogonal, simple enough, semantically clear,…
At that point, your code is who you are. This is the fundamental way programmers define themselves : through their code. Just like a painter is defined through his paintings, and a doctor by the way he treats his patients.
However, when my code is malfunctioning, or when someone is having problems with it, I assume that it is : flawed, buggy, unclear, too complex… in short, that it needs improvement. And strangely enough, it always does 
When you are writing code, you have to use the best of your abilities to strive for perfection, but as soon as you have written it, admit that you are not smart enough to do that.
“You are not your job. You are not how much money you have in the bank. You are not the shoes you wear. You are not the contents of your wallet.”
—you forgot “you are not your f$%ckin’ khakies…” 
I’m an internet developer and in the background I’m going to school to get my Masters in Psychology. During the workday, my mind often wanders to something I’ve learned from lecture and I realize how many IT people are enthralled with their “primadonna” status, or worse, fall into the subcategory of “geek with no social skills or veneer.”
I’m also a student of the Dharma (Buddhism) and I’ve learned that my feelings only get hurt when I am attached to something. If I can sit and invite “spaciousness” between me and the thing, I can usually invite the other opinion and actually grown and learn and become better at what I do.
Egoless development is the way to go. It doesn’t happen consistently for me. Sometimes I’m damn proud of my work. But it no longer defines who I am or how I feel about myself, and that correlates with the fact that no one else can tear me down by their criticism of my work.
It’s balances out! Thanks for your post. I enjoyed it.
The inverse is acceptance. If the code presented is not exactly what you would have done that does not automatically make it wrong. Even if you explained in detail what you wanted.
Look at the code, does it work correctly and is it clear. Remember you are not god.
I am a php developer and feel to be proud myself. But sometimes I become too much egoistic that I commit to do any thing, but It helps me, and boost me.
I’m not sure I agree with the quote from Code Complete. According to the book “Hackers” by Steven Levy, in the early years of programming the opposite was true. People would leave their source code (hand written at the time) lying around in desk drawers, free for anyone to make changes and improvements. They hated any attempts to restrict access to their source code, or to the machine.
The business people probably always viewed software, and hence source code, as being valuable, proprietary information. However, I don’t think the tendency for programmers to see their code this way crept into the mainstream until many years later.
There is an old joke that I read in an Isaac Asimov humor collection (not sure if he came up with it or just retold it) that goes something like this: A woman goes into a shop to buy a hat. The hat maker takes a length of ribbon, and deftly folds and twists it into a beautiful hat. “How much?” she asks. “Two hundred dollars,” he replies. “For a length of ribbon!?” she exclaims. He smiles and just as deftly disassembles the hat, and hands the ribbon to her. “For the hat, two hundred dollars. The ribbon is yours for nothing.”
To use this analogy, I think programmers are like the hat maker. In the olden days of programming, it was the art of creating the hat that excited and impressed people. These days, it is the collection of hats they have created.
There is no learning tool better than peer reviews and having other programmers contribute on how your code can be improved, if need be. However, this can only be done at a working place where coding standards and expectations are defined clearly. What may seem reusable to one programmer, can seem static to another.
It is hard to detach yourself from your work. I would certainly love to learn how. So, where do you start?