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, all programming related. While the later two aren't renowed for their high signal-to-noise ratio , mailing-lists are usually frequented by rather clueful people.
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 he 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 detail 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 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.
As you would expect, the main cause of obsolescence is of course age. It's hard to keep up with the furious pace of Information Technology, and having to learn a new thing to replace one you've mastered (or, even worse, haven't even mastered yet) is always tedious. This does not necessarily mean "old age", you can be caught by this phenomenon from time to time, on a given subject, while still being a beginner . The "Learning muscle" requires training to stay in shape, just as any other one.
Adding to this problem is the fact that, among the monthly crop of IT novelties, it can get pretty hard to know the weed from the chaff, but you can safely assume that 1% is worth a look and the remaining 99% is short-lasting buzz. Hence the understandable tendancy to dismiss it altogether, if only to wait and see what will actually last.
One would think that, in the case of a hacker, the sheer passion for everything technical discards the lack of learning will. This is indeed true most of the time. A hacker won't have a problem with picking up something new, because he likes it and he's good at it.
There are several other factors, among which :
All these traps are very easy to fall in, and it should be obvious that hackers are ideal targets for them, much more than people for whom programming is just a job. The fact that among the hacker's traits are ego, and the preference of elegant, and usually less "easy", solutions over dumb ones should also be considered as potential weaknesses rather than strengths, or as an hindrance to keep an open mind and improve one's skills, rather than an enticement to do so.
Experience shows that the only winning strategy in development is pragmatism : Use what works best. Linus Torvalds has directed the Linux kernel the exact same way so far, choosing a solution on proven technical merits rather than on an epidermic feeling. A more far-fetched example, but still relevant in a way, is Microsoft. The company got big in a large part because even when they had invested a huge budget on some project and the market wouldn't follow, they never had any second thought at scrapping it all, do an about face and follow the market (e.g. MSN vs. the Internet, Blackbird vs. Java - please, I'm not interested in discussing about other methods they may be using :-).
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 is even worse.
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. In particular, young Linux users migrating from Windows should keep in mind that the very impulse which drove them out of the Wintel rut can nail them dead on in another one.
 : 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".
 : 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.