Philosophy of Coding: Ego
This is a continuation of my thoughts about philosophy and coding. It is an exploration of how the way we think about coding impacts the coding process and the code that we produce. This particular article is reflection upon a book i read a year or two ago called “Ego is the Enemy”
Ego is the enemy
The title of the book says a lot. Ego is the Enemy. How does Ego show up in coding? It shows up in a couple ways and they are all destructive.
The Dogmatic Coder
One of the first lessons of software design (and most of life in general) is that the answer is always “It Depends.”
Sometimes coders can be very dogmatic. “My way of doing it is the only right way. If you do it some other way you are wrong.” It is very narrow minded and myopic. It is a symbol of self-absorbedness. One of the first lessons of software design (and most of life in general) is that the answer is always “It Depends.” Context is important. The correct answer for your situation, may not be the correct answer in other situations. I fully admit that I have been guilty of this in the past (and may sometimes still be) but I am very aware of it and am trying to improve.
The Lone Wolf Coder
For some reason in our culture we elevate the John Wayne rugged individualist who thinks they can do everything by themselves. This manifests itself in the form of lone wolf coders. Sometimes there is only one LabVIEW programmer in a company. These aren’t the people I am referring to here (although they could definitely benefit from community as well). I’m referring to programmers who even though there are other LabVIEW programmers around or even on the same team, they insist on doing everything themselves. It’s all about ego. In their mind, no one else can do it as well as they can. These are the guys who work best when you throw a problem over the wall to them and they lock themselves in their office for 3 months until they pop out with the answer.
It is antisocial behavior. They are depriving themselves of the opportunity to learn from others, and because of that likely spend much of their time reinventing the wheel. They are also depriving themselves the benefit of having someone else look at their code and perhaps point out some of the bugs that they missed. On top of that if they are truly as smart as they usually think they are, they are depriving everyone else of learning from them. Human beings are social creatures. We are meant to be in community and that is when we all perform our best.
The Clever Coder
Writing clever code may be fun, but inheriting it never is.
Ego often rears it’s head in the form of the clever coder. These are coders who like to figure out how to do 10 things in a single line of code. They pride themselves on how few lines of code they write. They also like to take advantage of weird little known side effects of functions. Now in general I am in favor of fewer lines of code. Fewer lines of code means less code to understand and less maintenance. However that really only applies if the code is simple and easy to understand. Code written by clever coders is rarely simple and often relies on very deep understanding of the bowels of the compiler, the OS, or some framework. Often clever coders don’t bother to document any of that deep intimate knowledge. Clever code is a nightmare to inherit. It is generally impossible to decypher if you are not the one who wrote it. Writing clever code may be fun, but inheriting it never is. Don’t be a clever coder.
The Overly Possessive Coder
As coders we can sometimes get over attached to our code babies. We don’t like other people poking around in code that we wrote. When it invariably needs to be updated, we want to be the one to update it instead of someone else. We justify it with idea that we know it better than anyone else. In reality it is often just ego. We wrap our identity up in “I’m the guy who wrote that awesome module for talking to the database.”
The Agile Samurai it mentions that in agile project no one person should own any chunk of code. It is all shared responsibility of the team. Now it is doesn’t directly say that in the agile manifesto, but if you think of agile as being able to respond to change, then running every change for a particular module through one person creates a bottlekneck and slows your ability to respond to change. Also one of the tenets of XP is pair programming, specifically so that everyone is familiar with every part of the code. When coders get over possessive it creates silos of knowledge, which slows you down.
