September 96 - THE VETERAN NEOPHYTE: Your Friend the Drill Sergeant
The Veteran Neophyte: Your Friend the Drill Sergeant
There are a ton of different ways to learn to shoot pool. You can just bash the
balls around, trying to pocket them, and eventually you'll get better at it.
You can play games with other people, which increases the motivation somewhat,
and probably learn a little faster. (Some people claim you should always play
for money, because it makes it matter so much more.) But one of the most
powerful ways to practice pool is plain old drill: setting up the same
situation over and over, trying to make the shot a little better, a little more
accurate, every time. Concentrated, repetitive drill is incredibly helpful in
the early stages of learning the game, but it doesn't stop there. Drill remains
a useful practice method virtually forever. Many experts who have been playing
for 30 years still do regular drills, and still benefit from them.
But this stands in sharp contrast to programming, another skill I like to
exercise (and analyze). Drill can be useful for programming neophytes, for
learning such things as typing and the syntax of the language. But no
experienced programmers I know engage in regular drill. The thought is actually
ludicrous. What would you do? Write the same loop over and over, trying to do
it a little faster or more accurately each time? Create a Hello World program
from scratch 100 times in a row so that it becomes automatic? I don't think
So what's the difference between learning programming and learning pool? Why
does drill have lasting value for one but not the other?
A worthy question, I thought to myself. It's deep enough that the answer should
take a while to find, and interesting enough that the journey will keep my
attention. So I girded myself for a long and arduous quest, set off smartly to
find the answer, and stumbled over it immediately: drill is useful for learning
mechanics -- like high-precision muscular tasks -- but it isn't very useful for
learning high-level problem-solving skills. Since experienced programmers spend
most of their time on problem solving and very little on mechanics, drill just
isn't an effective tool for getting better at programming once you're past the
Well, jeez, that was too easy. Isn't there more to it than that? Surely there
must be deep and profound differences between learning to shoot pool and
learning to program, since the tasks themselves are so completely different.
Programming is like -- well, you know what it's like, or you wouldn't be
reading develop. It's mostly abstract and logical, and most of the real action
takes place deep in your head or deep in the machine, far from the real world.
Shooting pool is something else altogether. It's unabashedly physical, it often
defies logic, and the action takes place where everyone can see it, on a huge
table made of wood and slate and rubber and cloth.
I started playing pool fairly seriously several months ago, and I'm still
embarrassingly terrible at it. In my typical overenthusiastic,
obsessive-compulsive fashion, I dove in with both feet: I researched pool at
the library, bought and read pool books, studied pool videotapes, cruised the
Net for pool stuff, and jabbered about pool to anyone who came within earshot.
The result was perhaps predictable. In no time, my knowledge of pool theory
completely outstripped my ability to put it into practice. So although I could
often see what to do in a certain situation, I couldn't actually do it. All
bark, no bite.
To rectify this situation I started doing the only thing that would help:
practicing doggedly. I took a lesson from a good instructor, and started
hanging out at the pool hall as much as possible, putting in the practice time.
Of course I was hoping that I'd suddenly make remarkable improvements in my
game. But remarkable improvement is tough to come by in pool.
At first glance pool seems like it should be very straightforward. You have
nearly perfect spheres undergoing nearly perfectly elastic collisions, so the
paths of the balls should be nearly perfectly predictable, right? Wrong. Like
most things that take place in the real world (as opposed to inside a
computer), there's a whole seething world of subtleties and nonlinearities and
complexities just beneath the surface. The actual grungy details -- the drag of
the cloth, the spin of the balls, the fleeting grip they have on each other
when they collide -- all affect the paths of the balls profoundly, and are so
complex and intertwined that people argue endlessly about what's really going
on. Superstitions, theories, rough approximations, and empirical formulas
abound. And all this complexity is set in motion in one tiny instant, by the
impact of a chalked leather cue tip on a smooth plastic ball for a few
milliseconds. If you ever needed an example of something with a sensitive
dependence on initial conditions, this is a doozy.
Because of its complexity and sensitivity, progress in pool is slow no matter
how you approach it. Playing pool is one of those things you can do all your
life and keep getting better at, like playing a musical instrument. And like
learning an instrument, just playing is lots of fun, and can be fine practice.
But concentrated drill on the basics, especially for a beginner like me, helps
in a way no other kind of practice can. When I started regularly doing drills,
the effect on my game was immediate and tangible (if not as remarkable as I
might have liked).
Good drill in pool involves intentional, conscious moving of your muscles the
same way over and over, paying attention to the details of arm position,
follow-through, rhythm, aim, and so on. You're trying to consciously train your
muscles to learn the motions, so that those motions can be performed
unconsciously later. To use a handy computing metaphor (always a good idea when
talking to programmers), drill is like programming an EPROM: it pushes
something that initially requires conscious control (the software) down into
the unconscious realm (the hardware). Drill helps you deliberately "wear
grooves" in your brain.
But that kind of "hardware" programming happens with any learning experience;
it's not unique to drill. In fact, that's what learning is. Drill is just one
kind of focused, repetitive practice that helps you learn certain things
faster. All learning involves pushing stuff "down into the hardware." (And I
mean that literally: scientists are starting to identify the physical changes
that happen in brains when animals learn.) To muddle my metaphors a little,
learning is like climbing an endless terraced hill, where what you learn
becomes the ground you stand on to reach the next level. Details that once
required your full attention get tucked down into the unconscious realm and are
hidden, in the same way that the details of your code get tucked down into
subroutines and are forgotten. The point is this: once you learn anything, you
can climb up on top of it, and other things that were unreachable before are
brought within your grasp.
In my zeal to uncover the differences between learning pool and learning
programming, I failed to notice the most remarkable thing of all: their
similarity. The two goals couldn't be more different. Programming is the
crafting of precision machinery in a tightly controlled environment; pool is
poking a ball with a stick (albeit in precise and skillful ways). Yet learning
the two skills -- for that matter, learning anything -- is the same process. In
fact, the more examples of learning I looked at, trying to categorize and
separate them, the more the differences faded and the similarities came into
In every case, learning is the same kind of journey. We climb that tiered
structure, that terraced hill, standing on what we've learned before so that we
can reach the new stuff. We slowly convert tasks that initially require our
full attention into automatic, mechanical ones, and that conversion to
mechanics is what allows us to turn our attention to more meaningful,
Attention seems to be the limiting factor here -- we don't have much of it.
Reaching once again for the low-hanging fruit on the computational metaphor
tree, attention is like a single-threaded program with a tiny stack: we can
only pay attention to a small handful of things at a time. The funny thing is
that our brains aren't single threaded at all. Far from it! They are
unbelievably prodigious and capacious things, and they actually are handling
all the details, all the way down. We just aren't aware of it. And believe me,
that's a good thing.
Without some way to convert conscious activities into unconscious ones, to push
the details down out of sight -- to program ourselves -- we'd never get
anywhere. Our meager helping of attention would be used up in no time. If we
had to struggle with typing and syntax on every line of code we wrote, we'd
never get the program written. If we had to consciously move each and every
muscle all the time, we actually wouldn't be able to walk and chew gum at the
same time -- plain old standing around would probably be out of the question,
much less hitting the cue ball with a little right English to sink the eleven
ball and go two rails down table to get position on the thirteen. Lucky for us,
the ability to program ourselves is built in. With a little desire and
disciplined practice, we can do truly amazing things.
And oh, I do want to sink that thirteen ball. I really, really do...
- Byrne's Standard Book of Pool and Billiards by Robert Byrne (Harcourt
DAVE JOHNSON (firstname.lastname@example.org) recently determined that there are 6451 books
currently in print whose titles begin with "How to..." He's wondering how he'll
ever find the time to read them all.
Thanks to Lorraine Anderson, Jeff Barbose, Brian Hamlin, Bo3b Johnson, and Ned
van Alstyne for their review comments.
Dave welcomes feedback on his musings, so please let him know what you