Comments by Scott Thompson and Elaine Ashton prompt an early Part II.
*Curiosity* is an essential trait for the programmer. In all seriousness,
if you don't have a deep desire to find out how things work - in
particular, software - this may not be the field for you. Principally
because our tools are rarely so perfect at encapsulation that they
completely hide the underlying mechanism, therefore, it is necessary to
understand the underlying mechanism and to want to get at it.
Now, I have to qualify and explain that statement. Take for example, a
modern automobile. It successfully encapulates the principles of internal
combustion engines such that a driver who doesn't want to know any more
about it than "Put gas in when this light goes on and take it to a service
station if any other light goes on" doesn't have to. The automobile has
shielded the driver from having to know about spark plug gapping, timing
advances, that sort of thing (not that plenty of owners don't get mileage
out of knowing those things anyway).
In computer programming, the C compiler manages to do the same thing; most
people don't need to dig below the level of C source any longer to find a
problem. (It wasn't always so; up to 10 years ago I used to have to go
into the machine code generated by a compiler on occasion because there was
a slight chance that the compiler had erred.) For the most part, the Perl
programmer can make the same claim. But what of the edifices we construct
with our high-level languages? By and large, applications rarely
encapsulate perfectly; there's always a need or substantial advantage to be
gained from ferreting about under the hood. In the last 10 years, this
need has only increased, in my opinion; I see more complex applications
coming to market in much shorter development cycles, and as a result a
product is more buggy, less complete, and less properly documented than one
from the year before. No matter how professional the product, somehow I
always end up relinking shared libraries, editing header files, writing
Perl 'glue', or some other kind of tinkering to get it to do what I want.
The need to delve into the workings of software is so pervasive that it was
encasulated long ago in an acronym that's also geekspeak: UTSL, standing
for "Use The Source, Luke". Telling someone to UTSL is also recognizing
that the source code itself is the ultimate authority on how it works and
sometimes nothing else can answer a particular question.
So we work in an imperfect field that requires that we often tear things
apart to make progress. How should a beginner leverage this
information? Firstly, as I said, realize that if you don't have a desire
to find out how things work *just for the sake of it*, you may not have fun
being a programmer. I know the obvious retort is, "I just want to get my
job done," but as I've been explaining, getting this job done usually
requires so much inquisitiveness that you'd better enjoy it.
Secondly, want to understand *everything*. Even if you leave some parts
until later because they're less interesting or less relevant, strive to
understand an entire process from top to bottom. It's amazing how often
there's useful information hidden inside some part that you thought was
perfectly encapsulated. Or that helps you understand higher levels:
learning how CPUs are constructed helps to understand why assembler is the
way it is, which helps to understand how higher-level languages are
constructed and why things like stacks and heaps are so important.
Thirdly, devour good examples of code that are just within or just beyond
your current understanding. They'll both broaden and deepen your expertise
as you see other ways of doing things you already know how to do, and are
forced to research new topics.
Finally, understand that the learning can never, ever, end. You'll know
that you're in the right place if this comes as good news.
Hmmm... FWIW, (c) 2001, Peter Scott
