"Being a hacker doesn't protect you from being outdated" - An opinionated, but very interesting and insightful, article about the "facts" and "causes" related to "hackers becoming outdated".
6399b290d3c8d4b634b037ddac18d38759842593a026b7af97bab1cf325f1f9d<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>Being a hacker doesn't protect you from being outdated</title>
</head>
<body>
<h1>Being a hacker doesn't protect you from being outdated</h1>
<p>Let's start with a few well-known facts :
<ul>
<p><li>Emacs (or XEmacs) is a slow and bloated piece of junk, a text
editor has no business being a mail and news reader.</li>
<p><li>Garbage Collection (GC) is for people who find it too difficult to
call free(). It is always possible to have nice matching
malloc()/free() pairs. If you can't, your design is broken (or use
static arrays, or quit programming altogether).</li>
<p><li>Object Oriented Programming (OOP) sucks, it makes things more
complicated, harder to debug, and produces bloated programs. Plain C
can always do the job just fine.</li>
<p><li>C++ is an inherently slow and bloated language. Multiple
inheritance is wrong, you can always do with single inheritance, and
if you really need it, Java interfaces are the right solution. The C++
Standard Template Library (STL) is totally useless, the GLib does
exactly the same job and is much lighter. Templates are a bad idea
anyway, you can achieve the same functionality with void pointers (or
virtual functions if you really have to). </li>
<p><li>Lisp is just a language to teach about linked lists and try to
do Artificial Intelligence. You can't possibly do anything useful with
it.</li>
<p><li>Goto's are evil and should never be used. Using a goto means
you're too lazy to write a clean, structured program.</li>
<p><li>Memory Protection is needed only because people are too lazy to
fully debug their code and are writing bad programs.</li>
</ul>
<p>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.</p>
<p>Note that none of these are from me directly. They were all picked
from mailing-lists, newsgroups, or <a href="http://slashdot.org">slashdot</a>
discussions, all programming related. While the later two aren't
renowed for their high signal-to-noise ratio <a href="#1">[1]</a>,
mailing-lists are usually frequented by rather clueful people.</p>
<p>But still, all these "facts" share two other more important
common points :
<ul>
<p><li> They are all false.</li>
<p><li> Considering them true means that you're missing a crucial
point, that a part of your mind has closed shut, and prevents you from
seeing any further, and expanding your technical skills.
</li>
</ul>
<h2>What this document DOES NOT talk about</h2>
<p>First and foremost : why (or if) any of these facts is true or
false. <i>I'm not interested in discussing any of them, please refrain
from emailing me about any of them</i>.
<p>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.
<h2>What this document DOES talk about</h2>
<p>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.
</p>
<h2>The Technician's Obsolescence Problem</h2>
<p>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.
<p>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.
<h3>The Most Usual Cause : growing old</h3>
<p>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 <a href="#2">[2]</a>. The "Learning muscle" requires
training to stay in shape, just as any other one.
<p>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.</p>
<p>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.</p>
<h2>Other Causes</h2>
<p>There are several other factors, among which :
<ul>
<p><li><i>Being content with one's skills</i> : You've reached the
level of competence which you were aiming at, consciously or not, and
are happily resting on your (maybe years old) laurels. You just aren't
interested in learning anything new.</li>
<p><li><i>Not having any external challenges</i> : A variant of the
previous one. Having acquired some sort of good reputation among your
peers (be they work colleagues or fellow hackers), you're convinced
that you're good. Nobody around you is better than you are, or has
skills you don't have.</li>
<p><li><i>Being a few against many</i> : Thinking that you know of
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). Using an alternative technology often gives
you a feeling of pride, because you feel being 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 greater number
tends to gravitate toward what sucks is a most supportive
argument.</li>
<p><li><i>Clinging to a tradition</i> : "This is how we've been doing
it all the time". 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.</li>
</ul>
<h2>Hackers can become outdated too</h2>
<p>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.
</p>
<p>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 :-).
</p>
<p>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.
</p>
<p>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.
</p>
<hr>
<p> <a name="1">[1]</a> : the term "slashdot reader" has more or less
acquired a derogatory and demeaning sense, see
<a href="http://www.labs.redhat.com/~sopwith/slashdot-twist.html">The Slashdot Phenomenon</a>
by <a href="mailto:sopwith@redhat.com">Elliot Lee</a>, and the the relevant
bits of <a href="mailto:esr@tuxedo.org">Eric Raymond</a>'s
<a href="http://www.tuxedo.org/~esr/writings/understand-my-job-please.html">"Understand my job, please"</a>.
<p><a name="2">[2]</a> : 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.
<hr>
<address><a href="mailto:glaurent@worldnet.fr">Guillaume Laurent</a></address>
<!-- Created: Mon Apr 5 10:02:31 CEST 1999 -->
<!-- hhmts start -->
Last modified: Fri Apr 16 18:55:28 CEST 1999
<!-- hhmts end -->
</body>
</html>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed