My career in computer programming started with a specific book that I found in the Hobbs (NM) Public Library in 1965, when I was 15. This book was an early example of what was later called “programmed instruction,” and I've been rather curious about the subject ever since. The link here is to the Library of Congress cataloging record for it:
Scott, Theodore G.
Computer programming techniques.
Doubleday, 1964. QA75.5.S38, LCCN 63020514.
I had never even seen a computer, but I was curious about computer programming, so I checked it out, read it from cover to cover, and absolutely loved it. I've been programming for a living ever since my freshman year of college.
The structure of this book, and the other TutorTexts that Doubleday developed, was quite unusual. After a brief introductory chapter that explained the structure, the content was provided as a maze of small chunks.
Each chunk would explain some concept or bit of technique. Then it would give you a question that asked you to apply it in a specific situation. For example, while learning assembly language programming, it might give you a short sequence of instructions and then ask about the contents of a register after these instructions were executed. If you think the register contained 5 afterward, turn to page 13B; if you think it contains 0, turn to page 17A.
If you picked the wrong answer, the referenced page would explain where you went wrong, and send you back for another try. If you picked the right answer, it would explain why it was right (in case you were guessing), pat you on the head for getting it right, and then move on to the next chunk of content. It was self-paced, and I think the author did a good job of anticipating the common misconceptions and helping the reader around them.
A few years later I talked to some professors at Stanford who were working on a huge project in what was called “CAI” or computer-assisted instruction. A lot of people thought it would revolutionize teaching. The hype I heard at the time never materialized they way they said it would.
So whatever happened to CAI?
I asked my friend Dr. Bob Cormack this question. Bob is a professor here at New Mexico Tech, with a dual appointment in Psychology and Education. The story he told encompasses much more than just CAI, narrowly defined, and is worth hearing.
Back when Russia sent Sputnik into orbit, there was widespread panic in the USA, fear that they had gotten ahead of us in technology. My own education benefited greatly from the accelerated math track that the Hobbs public schools added in response to this panic.
Cormack said that the US military was terrified by rumors that the Russians had a secret instructional technology that would train up their troops faster than our methods. So the Pentagon funded a huge study of instructional technologies of all kinds by the National Academy of Science: old, new, conservative, and crackpot. They even studied the effects of pyramids and crystals; no rumored technique was left uninvestigated.
Druckman, Daniel, and Robert A. Bjork, editors Enhancing human performance: Issues, theories, and techniques National Academies Press, April 6, 1988 ISBN 978-0309037877
Druckman, Daniel, and Robert A. Bjork, editors In the mind's eye: Enhancing human performance National Academies Press (January 1, 1992) ISBN 978-0309047470
Druckman, Daniel, and Robert A. Bjork, editors Learning, remembering, believing: Enhancing human performance National Academies Press, January 1, 1994 ISBN 978-0309049931
Cormack sums up this study this way.
I was quite interested to hear about these cultural barriers, especially in view of the way that students raised in Chinese and Japanese cultures often surpass others in the USA academically to an extent that is statistically significant.
When trying out a new skill or craft or discipline, a person might have a little success, and then conclude that they have the skill, and move on to something else.
For example, I might read the proof of a mathematical theorem and think I understand it. I feel that I could reproduce it. But when put to the test, I often find that I can't do it.
I've been programming for 45 years now, and it continually amazes me how work I did two years ago falls short of the level of my current practice. Just about anything you put your effort into will turn out to be far deeper and more subtle than you realized. But you have to stick with it to find that out.
New Mexico Tech, where I work, has a lot of really sharp students, and they are quite justified in being proud of their work. Many of the computer science majors I know are suitably humble about how small they are in comparison to a field that has grown to be quite wide and deep. But I well remember how smart I was at 19, and how far more stoopid I am now.
At one point I was arguing with a student in his early twenties about program documentation. I said, “In all the software shops where I've worked, there is a pretty wide range of opinion on how much documentation is the right amount, and how to do it. But having no documentation at all, not to mention no comments in the code, is completely outside that range.”
He replied, “Well, we'll just have to agree to disagree about that.”
I can understand feeling the way he feels, because I was that age once. But writing student programs that get thrown away the day after they are graded does little to convince you of the need for documentation. It's only when your programs persist, and get fixed and enhanced, and beaten on by ignorant or malicious users, that you realize that good design and documentation are not optional features.
Competence is not something you just acquire and that's that. It's open-ended. I don't feel that I have mastered computer programming. I think my work gets better every year, but that's no reason to be complacent.
The second cultural barrier to learning is illustrated by asking a number of people if they ever learned to play the piano.
In Western cultures, a typical answer is, “I tried that once” or “My parents made me take lessons,” but then often they add “but I didn't have any talent for it.”
In Asian cultures, you would be more likely to hear, “I don't play piano well because I never put in the work required.”
Here's an excellent, recent book that underscores this point.
Levitin, Daniel J.
This Is Your Brain on Music: The Science of a Human Obsession.
Plume/Penguin, 2007, ISBN 0452288525.
Levitin makes the point that the single common attribute of great musicians is that they have spent around 10,000 hours practicing. He too is skeptical whether some innate “talent” is the main component of the skill level of a Yo-Yo Ma or a Joshua Bell.
Now, obviously, you have to be pretty motivated to spend 10,000 hours of your life deepening and widening your ability in some field. But the motivation is not enough. You have to put in the work.
It's a harsh truth, but there just is no golden road, no silver bullet, that grants you profound ability.
In many cases, the way your mind and body work, whether shaped by nature or nurture, certainly affect how quickly you can acquire in a skill. In some cases, as with a seven-foot gymnast, you may not really be cut out for it.
Cormack has a wonderful metaphor for discussing the relative values of nature (genetics) and nurture (environment) in the acquisition of competence: if you are computing the area of a rectangle, which is more important—length or width?
Some friends of mine read an early version of this essay and took exception to took the extreme position I took in that version, that talent is nonexistent: there is only work.
If two motivated people each spend ten hours practicing a piano piece, they will both improve, but some people will improve at a faster rate than others.
So now I understand “talent” as a multiplier of effort: some people get more than others from the same effort, and we might say that they are more talented.
But a multiplier must have something to multiply. High talent times zero effort still equals zero improvement. Progress still depends primarily on putting in the work.