March 28, 2009 will

On Ego and Software Development

I've been thinking a lot about ego lately, and how it applies to software development. Writing software – like any other human endeavor – is influenced by the need to be recognized and hopefully praised for our work. I am no different; it is most likely ego that drives me to release open source software and to refine it even when there is no direct benefit to be had for that work. In this respect, ego is beneficial as it compels me to writer better code, but in the context of a day-job work, ego is a liability.

He peruses the code and deduces that he is a superior developer to the schmuck that put it together originally…

Consider a developer who inherits a hefty code-base written by another company or a long-departed contractor. He peruses the code and deduces that he is a superior developer to the schmuck that put it together originally; his code would have solved the issues more elegantly and be more flexible.

Although most likely fueled by ego, he may be correct – the difference between a poor developer and a good developer can be several orders of magnitude in terms of code quality, but it is what he does next that may be driven by ego.

Functional code is functional code; if it is a black box that runs fast enough, does exactly what it says on the tin and has no unintended consequences then it is largely irrelevant how elegantly (or not) it is put together. But when the ego comes in to play the developer thinks to himself “my code would be vastly superior!” and he endeavors re-write it in some misguided attempt to show the original developer how to do it properly. Thats not to say that code should never be re-written, but just that a decision motivated by ego is most likely the wrong one.

Another trap that the ego can lay for the software engineer is that it can hide the point where code has become unmaintainably complex. Most developers will have worked with code that is so fiendish and sophisticated that only the original author has any chance of making changes to it, and even then it takes way to long to make modifications. This rarely occurs because the problem domain is so difficult that only an engineer savant could possibly create the solution – it occurs because as each new requirement is tacked on to the original solution the developer is thinking “No problem, I am smart enough to understand this”.

The best developers – in this blogger's humble opinion – are those that show a wee bit of humility. If you talk to experienced developers, well respected in their particular niche, you will probably find that although they show pride for their accomplishments they are acutely aware of mistakes they have made, often to the point of being embarrassed about their code.

I'm not suggesting that ego is always a bad thing, or that it is necessary to enter in to some Zen-like nihilistic state before sitting down to the keyboard and tapping out code, just that ego should be shelved until after the project has been completed – then is the time to punch the air and do hip thrusts at the monitor.

Use Markdown for formatting
*Italic* **Bold** `inline code` Links to [Google](http://www.google.com) > This is a quote > ```python import this ```
your comment will be previewed here
gravatar
Eric Kow
Not that this is very relevant, but what makes you presume that a Zen-like state is a nihilistic one? From my understanding of it, a Zen-like state would consist of wholehearted hacking: 100% planning/refactoring/coding, 0% thinking about how much better/worse a programmer you are than the other guy :-)
gravatar
George
“Most developers will have worked with code that is so fiendish…”

Sometimes by design. ;-)

Way back in the day, a small part of my job was to support a manager who wanted last period's and this period's blah-blah report side by side, with the equivalent rows of text lined up on 11“ X 17” line-printer paper.

My predecessor had used about 100 FORTRAN cards for the job. It was the worst tangle of computed goto spaghetti I've ever seen, including so few lines of old-school BASIC.

I couldn't resist trying to figure it out for a couple of hours, but (rim shot) it worked, and I never had to change it. :-p

The guy's other stuff was good, so I figured he'd done that piece on purpose. Hours and hours punching cards, drinking horrible vending machine coffee from tiny cardboard cups, pacing the halls waiting for output, watching the sun come up, …. Makes me shiver, even now.
gravatar
Reba
In a software developer, the ego factor might be called for in the sense that a developer needs to be pretty confident of whatever dramatic paths are opted for, which is in a way a precondition for creativity.

On the other hand, changes made for the sake of merely beating the other guy are doomed for failure - while developing software (or doing any other kind of meaningful activity) you have to focus on what is being done, and not how it has been or could have been done previously.
gravatar
magtak
Weirdly enough i am a junior dev on an internship.

I am @ work and i was way too bored/out of mood today to continue my application so i've spent pretty much the whole day googling stuff - mainly about psychology and the power of ego. So an article about ego and software development? Weeeeeiiirrdd…. ;)
gravatar
Nicholas
Thanks for writing this.

I propose that ego, if defined correctly, only serves to negatively impact what is produced. The best code meets the needs of the user in terms of functionality, the tester in terms of testability, the fellow developer in terms of readability and maintainability, etc.

There is plenty of joy in serving others, that does not require us to feed this idea of who we are and how special we are. Serving our identity of ourselves can only compete with serving others. To borrow from Software Engineering, when a group of people are involved (like multi-person software project) only one of those paths can scale.