The Veteran Neophyte: Your Friend the Drill Sergeant

Dave Johnson

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

• Byrne's Standard Book of Pool and Billiards by Robert Byrne (Harcourt Brace, 1987).

---

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.