programming and human factors
by Jeff Atwood
The concept of egoless programming, as described by Johanna Rothman:
Twenty-five years ago, Jerry Weinberg published The Psychology of Computer Programming. I discovered the book in 1977, and decided I wanted to work as an egoless software engineer, not as a radio disk jockey.Egoless programming occurs when a technical peer group uses frequent and often peer reviews to find defects in software under development. The objective is for everyone to find defects, including the author, not to prove the work product has no defects. People exchange work products to review, with the expectation that as authors, they will produce errors, and as reviewers, they will find errors. Everyone ends up learning from their own mistakes and other people's mistakes. That's why it's called egoless programming. My ego is not tied to my "perfect" or "imperfect" work product. My ego is only tied to my attempts to do the best job I know how, and to learn from my mistakes, not the initial result of my work.
It's important to disconnect your idea of self-worth from your job function.
I am reminded of these quotes from the movie Fight Club:
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.
It's a lot easier to embrace criticism of your work when you don't let your work define who you are.
Unfortunately, the world is full of people who don't give a damn about their work. Those of us who love programming enough to become highly skilled at it tend to have the opposite problem-- we care too much:
In the early years of programming, a program was regarded as the private property of the programmer. One would no more think of reading a colleague's program unbidden than of picking up a love letter and reading it. This is essentially what a program was, a love letter from the programmer to the hardware, full of the intimate details known only to partners in an affair. Consequently, programs became larded with the pet names and verbal shorthand so popular with lovers who live in the blissful abstraction that assumes that theirs is the only existence in the universe. Such programs are unintelligible to those outside the partnership.
That's one of my favorite quotes from Code Complete; it's attributed to Michael Marcotty.
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.
Mike Woodhouse on May 16, 2006 2:47 AMThe 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.
Ken Foskey on May 18, 2006 6:30 AMI 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.
Shadab on August 24, 2006 4:59 AMI'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.
Jake Cohen on March 23, 2007 5:35 AMThere 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?
Rita on August 12, 2008 5:29 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |