Partially rewritten - Aug. 8th 2000
Let's start with a few well-known facts :
At this point, chances are that at least a couple of these statements above ring very true to your ears, while you'll find the others totally ludicrous.
Note that none of these are from me directly. They were all picked from mailing-lists, newsgroups, or slashdot discussions (granted, probably not the best place to look for sound technical advice[1] :-), all programming related.
But still, all these "facts" share two other more important common points :
First and foremost : why (or if) any of these facts is true or false. I'm not interested in discussing any of them, please refrain from emailing me about any of them.
Another issue I'm leaving aside is of course personal taste. One can choose to dimiss a technology because one simply doesn't like it, or is not comfortable using it. While this can be a problem in the overall course of a programming career, it's a much less serious one than blind rejection on false grounds.
The point of this article is to attempt to illustrate the reasons which can lead a programmer on this most traveled path, and to show that being a hacker (here used in a somewhat wider sense of the term than usual, "programming nerd" would probably be more appropriate) in no way prevents you from following it. Quite the contrary, it can be an incitement.
Anyone who has worked in the IT industry is aware of the "technician's obsolescence" problem. At some point in his career, a technician's skills (and thus himself) become irrelevant. Most, if not all, of what he knows is outdated and has been supplanted by new techniques, usually more efficient.
Usually, the Dilbert Principle[2] has kicked in before this happens, and that technician has become a manager. The kind which you try not to discuss technical issues with, because you know he just won't understand[3].
Besides growing old or disinterested, several causes can lead a hacker to a state of relative irrelevance. This causes pertain to the fact that a hacker is by definition a highly skilled technician.
You've reached the level of competence which you were aiming at, consciously or not, and are happily resting on your laurels - even if they're getting a bit dusty. You just aren't interested in learning anything new. This typically happens when you've mastered a tool or a language. The better you are with it, the harder it will be for you to let it go. For instance, C hackers claiming that you can reproduce every C++ feature in C, or Emacs users that etags is just as good as any IDE's symbol browser.
A variant of the previous one. Having acquired a fair reputation among your peers (be they work colleagues or fellow hackers), you're convinced that you're good. Everybody around you treats you as a master of your craft, and hardly anybody questions your point of view.
Thinking that you either know or have understood something that everybody else is missing (and bragging about it). This is most common among users of a "minority OS" (e.g. anything but Windows), and even more in the hacker culture as opposed to the software industry (although such divergence among hackers are quite common). Consider the systematic rejection of anything from Microsoft by most Linux users, for instance.
Using an alternative technology often gives you a feeling of pride, because you feel you're part of an enlightened minority, hence an elite. The fewer people agree with you, the truer your opinion feels to you. The old cliche that the crowd tends to gravitate toward what sucks is a most supportive argument ("eat shit - 4 billion flies can't be wrong").
"This is how we've been doing it all the time". Example of this abound, for instance the resistance of many Unix hackers against IDEs or any other programming tool beyond a text editor, make and a compiler. This is "the proven way of development under Unix", so there's no reason it could be changed, right ?
In the case of the industry, this is a derivative of the first factor, e.g. age. Working in a hi-tech environment doesn't prevent you from getting hard-to-shake habits. In Hackerdom, the "tradition" feeling is much stronger, because you care for what you're doing and how you are doing it (especially as opposed to how the software industry is doing it, see previous point). The craft is actually a part of the culture.
All these traps are very easy to fall in. It's obvious that hackers are ideal preys for them, to a much greater degree than people for who programming is just a job. It is commonly admitted that among the typical hacker's traits are ego, and the preference of elegant solutions over dumb ones. The problem is that an elegant solution may be less efficient or a dumb solution may be practical. These traits can play against you and prevent you from keeping an open mind and improving your skills.
Of course, always doing so is next to impossible. We all have pre-conceived ideas, and admitting that you're wrong is always difficult. Also, as noted before, personal taste does play an important part. When it's about using a tool or a language, you will always be more efficient using a technique you know and like but which, strictly speaking, is less effective than another one which you don't know and dislike. Always falling for the new buzzword won't lead you very far either.
However, I hope that this short discussion may hint some people into trying to revise some too radical opinions they may have, to check if they aren't in fact "missing something", and being too quick to leave aside some tools which they might find invaluable further down the road.
[1] : the term "slashdot reader" has more or less acquired a derogatory and demeaning sense, see The Slashdot Phenomenon by Elliot Lee, and the the relevant bits of Eric Raymond's "Understand my job, please".
[2] : " The most ineffective workers will be systematically move to the place where they can do the least damage : management".
[3] : On the other hand, I've had the pleasure to work with an IBMer who, at the age of 50, was still curious and interested in new stuff, and eager to use it whenever he had the chance. There is no fatality here.