Priming the Pump
I’ve been in a learning mode recently. When I’m in a
learning mode I turn my attention to the stack of unread technical books on my shelf
and I start running through them. Not everyone likes reading books to learn
about programming. Books can be boring, take a long time to read and in general
not measure up to “hands-on” experience.
I think this analysis is a little simplistic. Yes, if I had
to choose between two people to work with and all I knew was that one had been
programming in C# for a couple of years and the other had read 10 books about
it, but never programmed in it, I’d choose the first guy.
However, this is really not going to happen. For me to get
to that point, I would have to have messed up entirely on the information gathering
stage of my decision making process. At that point, I might as well select at
random.
In a more realistic scenario, I’d know more about someone
then just one line item about reading books or not; and in a realistic scenario
I might not really care if someone had experience in the particular language we
were going to use.
In my view a good programmer can pick up any language you
throw at them. What’s more important is how they approach the problem at hand, what
kind of solutions they come up with, etc.
Now, while these traits can be illustrated by experience,
they also can be enhanced by some background reading. So when I read a book
about developing web applications with Ruby I am in a sense seeding my brain
with bits and pieces of ideas that I can hopefully apply to diverse situations
as I encounter them in the future. In a sense, I am “priming the pump” so that
my programming experiences can be more fruitful.
A perfect example of this is design patterns. The point of
reading about them is not to necessarily write an application that perfectly
implements the Observer pattern. The point is to have a ready store of ideas in
mind when you come across the type of problem the Observer pattern is typically
used to solve.