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.
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 early stages.
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 focus.
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, higher-level tasks.
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...
RECOMMENDED READING
DAVE JOHNSON(dkj@apple.com) 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 think.