Knowing and Doing

This week I ran across a link to an old essay called Good Writing, by Marc Raibert. By now I shouldn't be so happy to be reminded how much good programming practice is similar to good writing in general. But I usually am. The details of Raibert's essay are less important to me than some of his big themes.

Raibert starts with something that people often forget. To write well, one must ordinarily want to write well and believe that one can. Anyone who teaches introductory computer science knows how critical motivation and confidence are. Many innovations in CS1 instruction over the years have been aimed at helping students to develop confidence in the face of what appear to be daunting obstacles, such as syntax, rigor, and formalism. Much wailing and gnashing of teeth has followed the slowly dawning realization that students these days are much less motivated to write computer programs than they have been over most of the last thirty years. Again, many innovations and proposals in recent years have aimed at motivating students -- more engaging problems, media computation, context in the sciences and social sciences, and so on. These efforts to increase motivation and confidence are corporate efforts, but Raibert reminds us that, ultimately, the individual who would be a writer must hold these beliefs.

After stating these preconditions, Raibert offers several pieces of advice that apply directly to computing. Not surprisingly, my favorite was his first: Good writing is bad writing that was rewritten. This fits nicely in the agile developer's playbook. I think that few developers or CS teachers are willing to say that it's okay to write bad code and then rewrite. Usually, when folks speak in terms of do the simplest thing that will work and refactor mercilessly, they do not usually mean to imply that the initial code was bad, only that it doesn't worry inordinately about the future. But one of the primary triggers for refactoring is the sort of duplication that occurs when we do the simplest thing that will work without regard for the big picture of the program. Most will agree that most such duplication is a bad thing. In these cases, refactoring takes a worse program and creates a better one.

Allowing ourselves to write bad code empowers us, just as it empowers writers of text. We need not worry about writing the perfect program, which frees us to write code that just works. Then, after it does, we can worry about making the program better, both structurally and stylistically. But we can do so with the confidence that comes from knowing that the substance of our program is on track.

Of course, starting out with the freedom to write bad code obligates us to re-write, to refactor, just as it obligates writers of text to re-write. Take the time! That's how we produce good code reliably: write and re-write.

I wish more of my freshmen would heed this advice:

The first implication is that when you start a new [program], there is nothing wrong with using bad writing. Your goal when you start is to get your ideas down on paper in any form you can.

For the novice programmer, I do not recommend writing ungrammatical or "stream of consciousness" code, but I do encourage them to take the ideas they have after having thought about the problem and expressing them in code. The best way to find out if an idea is a good one is to see it run in code.

Raibert's other advice also applies. When I read Spill the beans fast, I think of making my code transparent. Don't hide its essence in subterfuge that makes me seem clever; push its essence out where all can see it and understand the code. Many of the programmers whose code I respect most, such as Ward Cunningham, write code that is clear, concise, and not at all clever. That's part of what makes it beautiful.

Don't get attached to your prose is essential when writing prose, and I think it applies to code as well. Just because you wrote a great little method or class yesterday doesn't mean that it should survive in your program of tomorrow. While programming, you discover more about your problem and solution than you knew yesterday. I love Raibert's idea of a PRIZE_WINNING_STUFF.TXT file. I have a directory labeled playground/ where I place all the little snippets I've built as simple learning experiments, and now I think I need to create a winners/ directory right next to it!

Raibert closes with the advice to get feedback and then to trust your readers. A couple of months back I had a couple of entries on learning from critics, with different perspectives from Jerry Weinberg and Alistair Cockburn. That discussion was about text, not code (at least on the surface). But one thing that we in computer science need to do is to develop a stronger culture of peer review of our code. The lack of one is one of the things that most differentiates us from other engineering disciplines, to which many in computing look for inspiration. I myself look more to the creative disciplines for inspiration than to engineering, but on this the creative and engineering disciplines agree: getting feedback, using it to improve the work, and using it to improve the person who made the work are essential. I think that finding ways to work the evaluation of code into computer science courses, from intro courses to senior project courses, is a path to improving CS education.

This last bit of advice from Raibert is also timely, if bittersweet for me... In just a few days, PLoP 2007 begins. I am quite bummed that I won't be able to attend this year, due to work and teaching obligations. PLoP is still one of my favorite conferences. Patterns and writers' workshops are both close to my heart and my professional mind. If you have never written a software pattern or been to PLoP, you really should try both. You'll grow, if only when you learn how a culture of review and trust can change how you think about writing.

The good news for me is that OOPSLA 2007, which I will be attending, features a Mini-PLoP. This track consists of a pattern writing bootcamp, a writers' workshop for papers in software development, and a follow-up poster. I hope to attend the writers' workshop session on Monday, even if only as a non-author who pledges to read papers and provide feedback to authors. It's no substitute for PLoP, but it's one way to get the feeling.

I recently realized something.

In books with academic settings, one often sees images of the professor, deep in thought, strolling along the tree-lined walks of campus. Students bustle about on the way between classes. The professor walks along, carefree, absorbed in whatever interesting problem has his or her mind. (All too often, it's a him.) Even if he is running late, has a meeting to attend or a class to lead, he hurries not. He is a professor and leads a life of his own design, even if administrators and students try to impinge on his time. Whatever deep thought occupies his mind comes first. So peaceful.

Movies show us these images, too. So peaceful.

I've never been like that. My campus setting looks much like the ones described in books and movies (though lately ours has looked more like a construction zone than an old-Ivy plat), but I always seem to be in hurry. Can't be late for class, or late for that meeting. Too much to do.

I've often asked myself, when will it be like in the books and movies.

My realization: The problem isn't with my campus or even my university. It's me.

The images in the books and movies are different because the prof ambling peacefully along isn't me. It's Professor Kingsfield. Many of these characters are clichés even when done well, but in any case they are different from me.

The only way for me to live out those images is to modify my own behavior or outlook. Peace comes from inside, not out there. But I don't think I am in need of a change... I'm not restless or dissatisfied; I'm just busy being me, solving problems and thinking about the latest something to cross my path.

So maybe what I need to change is my expectation -- the expectation that I can or even should be like the fictional people I see in those scenes. I suspect that having unrealistic expectations is the cause of as much disharmony as having the "wrong outlook". The outlook isn't always wrong. Sometimes it's just me.

Today I "refactored" the web page for a class session, along with files that support it. I used scare quotes there, but my process really was affected by the refactoring that we do to our code. I can probably describe it in terms of code refactorings.

Here is what I started with: a web page that loads thirteen images from a subdirectory named session02/, and a web page that loads two images from a subdirectory named session03/.

Due to changes in the timing of presentation, I needed to move a big chunk of HTML text from Session 3 to Session 2, including the text that loads the images from session03/.

In the old days, I would have cut the text from Session 3, pasted it into Session 2, renamed the images in session03/ so that they did not clash with files in session02/, moved them to session03/, and deleted session03/.

Along the way, there are a number of mistakes I could make, from inadvertently overwriting a file to losing text in transit by bungling a few keystrokes in emacs. I have done that before, and ended up spending precious time trying to recover the text and files I had lost.

I did something different this time. I didn't move and delete files or text. First, I copied text from one page to the other, allowing Session 2 to load images from the existing session03/ directory. I tested this change by loading the page to see that all the images still loaded in the right places. Only then did I delete the text from Session 2. Next, I copied the images from session03/ to session02/, using new names, and modified the web page to load the new images. I tested this change by re-loading the web page to verify the lecture. Only then did I delete session03/ and the images it contained.

Everything went smoothly. I felt so good that I even made a subdirectory named sample-compiler/ in the session02/ directory and moved the images in session02/ associated with the sample compiler -- one of the original session02/ images plus the two originally in session03/ -- down into the new subdirectory. I made this change in a similarly deliberate and safe way, making copies and running tests before removing any existing functionality.

When I got done, I felt as if I had applied to common code refactorings: Move Method and Extract Subclass. The steps were remarkably similar.

My description may sound as if this set of changes took me a long time to effect, but it didn't. Perhaps it took a few seconds longer than if I had executed a more direct path without error, but... I moved much more confidently in this approach, and I did not make any errors. The trade-off of deliberate action as insurance against the cost of recovering from errors was a net gain.

I refactored my document -- really, a complex of HTML files, subdirectories, and images -- using the steps like those we learn in Fowler and Kerievsky: small, seemingly too small in places, but guaranteed to work while "passing tests" along the way. My test, reloading the web page and examining the result after each small change, would be better if automated, but frankly the task here is simple enough the simple "inspect the output" method works just fine.

The ideas we discover in developing software often apply outside the world of software. I'm not sure this is an example of what people computational thinking, except in the broadest sense, but it is an example of how an idea we use in designing and implementing programs applies to the design and implementation of other artifacts. The ideas we discover in developing software often apply outside the world of software. We really should think about how to communicate them to the other folks who can use them.

Running on the university track late last week, I saw this slogan on the back of a student's T-shirt:

All out. All the time.

Such slogans are de rigeur for high school sports teams these days. They serve as mantras for the team, used to motivate the individual athlete but even more so to build team identity and spirit. I don't remember when I saw the first of these, but these days every team has one.

The folks at Despair.com have profited from pointing out how shallow and lame such slogans and motivational tools are. But I cut most of these T-shirts some slack, because they are aimed at kids, who are not perhaps at a deep level when it comes to motivation. I do hope that the involved coaches help their student-athletes move on to a deeper understanding of teams and motivation, both individual and group, than the slogans give.

But more importantly, I hope that these young athletes know that -- taken literally -- these slogans are usually wrong.

"All out. All the time." Any runner knows that this can't be true. If you run all out for any length of time, your body will let you know that won't be doing it all the time. Sprint 200 meters all out, and you'll need to recover. (Most coaches recommend at least 100m of recovery, or the same amount of time it took you to run the 200.) If you try to sprint 400 meters at the same pace that you can sprint 200 meters, then you'll usually fade fast at the end. Move all the way up to a marathon, and you have to make serious changes in your expected pace. That's just the our bodies work.

The same is true in any sport, along some dimension of exertion.

The same is also true in creative work. And in software development.

One of the great elements of Extreme Programming is the practice originally dubbed 40-hour work week and later renamed sustainable pace. Kent and Ward recognized that developers can't produce good code if they work beyond the pace that their minds and bodies allow. Ignoring those natural bounds is no different than trying to run your 200m pace for 400 or 800 or 1600 meters -- or for a marathon. If you try to go too fast for too long, you'll fade. That's not good for your client, and it's not good for developers.

There is a time for sprinting, surely, but software development and good relationships with customers are more of a long-term affair. Sprint in short bursts where that adds value for the customer and doesn't hurt the developers. But back off the throttle as a long-range plan.

The runners wearing slogans such as "All Out. All the Time." must know that they can't actually go all out all of the time. If they could, then I would never be able to pass them on the track with my tired old body, which most surely cannot go all out all of the time. But like them, I do like to go all out some of the time -- it feels good! And sometimes I myself will use even shallow, emotional sentiments to push myself when I am at the boundaries of what I think I can accomplish.

But then I take a recovery break.

Here is security, which comes along with my new favorite error message:

Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes.

Oh, yeah -- be sure to type it twice.

I leave it to the TheoryCS guys at Ernie's 3D Pancakes, Computational Complexity, and The Geomblog to give us the mathematical picture on how secure an 18,770-character password is, and what the implications are for installing SP1, before which you could get by with a passcode of a mere 17,145 characters.

After six months of increased blogging output, if not blog quality, August has hit me head on. Preparing for vacation. Vacation. Digging out of backlog from vacation. Getting ready for fall semester. The start of the semester.

At least now I have some time and reason to spend energy on my compilers course!

The algorithm geeks among you might enjoy this frequently-referenced and very cool demo of a graphics technique called Content-Aware Image Sizing, presented by Ariel Shamir at SIGGRAPH earlier this month (in San Diego just before I arrived for the above-mentioned vacation). I think that this will make a neat example for my algorithms the next time I teach it. (It's on tap for next spring.)

Algorithmically, the idea is cool but seems straightforward enough. To me, what is most impressive is having the idea in the first place. One of the things I love about following research in other areas of computer science -- and even in areas far beyond CS -- is seeing how thinkers who understand a domain deeply create and apply new ideas. This particular idea will be so useful on the web and in media of the future.

The guy who sent the link said it well:

SIGGRAPH has a way of reminding me that in many ways I'm the dumb kid at the back of the classroom.

I feel the same way sometimes, but I usually don't mind. There is much to learn.

Still, I hope that by the end of this semester my compilers students don't feel this way about compilers. I'd like them to appreciate that a compiler is "just another program" -- that they can learn techniques which make building a compiler straightforward and even fun. What looks like magic becomes understanding, without losing its magical aura.

Sometimes the best way to help someone learn a new habit is to let him or her feel the action happening, or not happening, in a new way. Sometimes, the action seems more natural when this feeling strikes a new chord.

I proposed an example of this approach many posts ago, in an entry called I Feel Good. I Feel Great. I Feel Wonderful. It reported an agile development fantasy I had after watching the Bill Murray flick What About Bob?. In my fantasy, I might use Dr. Leo Marvin's "Death Therapy" in an agile development scenario: Walk in one morning unannounced, and pull the plug on the project. An agile team should have something pretty reasonable to deliver. But would my students stone me before I could exit the room?

I managed to catch the beginning of a thread on the XP mailing list for once, a thread titled Your favorite teaching tricks?, launched by William Pietri. Unfortunately, this thread lasted only two messages, but both were valuable.

Pietri tells a story that displays one of his tricks for getting developers to write tests:

Friday night, I hung out with a pal who has been learning TDD. He is naturally full of questions, and one exchange went like this:

"If I have tested all the low-level methods, I don't need to test the components together, do I?"

"Did you run it to see if it worked?"

"Sure! I tried a few different options, and carefully looked at the output to be sure it was ok."

"If you had to check it, then you weren't sure it worked. Ergo, you should have written a test."

"Doh!"

Most developers already test in this way, writing simple little main programs that exercise their code. (Heaven help those who don't do at least this much -- and the people who use their code!) Why not automate that test? It's a small step from a handcrafted main to an xUnit test. And in my experience, that little main grows into an unmanageable mess. The xUnit test can grow gracefully into a suite of tests. (That doesn't mean you can't create an unmanageable mess, but at least we have a good book to help us get things right.) And from writing our post facto tests in xUnit, it's a somewhat larger but still small step to writing the test first.

J. B. Rainsberger followed up with a trick of his own, for working with customers:

I have one to help customers describe customer tests. If they seem not to want to do it, or have trouble, then when they ask me to build the feature, I immediately say "Done!"

They look puzzled. "You are not."

"Sure I am. Done!"

"You haven't done anything!"

"How do you know?"

The next thing out of their mouth is usually something we can easily turn into a customer test.

Very nice. I can't wait for one of my students to pull this on me for one of my underspecified assignments! Rainsberger does warn that this trick works best "only if you have a good personal relationship with the person acting as customer". So perhaps only those students who have developed a relationship of trust with me will want to venture this.

Of all the runaway threads on the XP list, this is one that I would like to have seen run longer. I'd love to hear others share some of their tricks at helping developers become more agile, whether in testing, pairing, refactoring, or any other practice.

On the plane back from beautiful southern California, I read Seth Godin's 2005 book All Marketers Are Liars. A few months ago, I wrote a short essay in which I considered the role of persuasion in teaching, and using what we know about how the brain works to reach students. Viewed cynically, this becomes more marketing than substance. Godin confronts this sort of cynicism about the business of marketing head on and refuses to shrink from connotation. To him, marketing is not hype and spam and telemarketers reading from scripts; those are mere bastardizations of a universal truth about buying and selling and stories. This book presents Godin's theory and practice of effective and responsible marketing. He accepts the verb "to lie", with a twist from how we usually apply it to marketing.

As I wrote in that earlier essay, and in several more since on stories, I believe something that Bruce Schneier and Kathy Sierra have said, that it's okay -- even wise -- to use what we know about how people think to help us change what people think. Sierra boldly suggests that this applies to what teachers do -- even teachers of computer science. So Godin's book left me wondering...

If some of teaching is marketing, and some of marketing is lying, is some of teaching lying?

Yes, I think it is, in the sense that Godin uses the term.

A teacher is telling a story. For this story to be effective, it must be one that the listener already believes, or at least almost believes. A good teacher meets her students where they are, working within their existing world view, starting with what they already know and believe. She works to help them to "buy into" the story, to actively participate in the story, to be complicit in telling the story to themselves.

Godin goes farther. We all hope that teachers rise above the stereotypical used car salesman by speaking truth. Godin tells us that, while the best marketers may not speak the whole truth and nothing but the truth all of the time, even they must be authentic. They must live lives congruent with the story they tell; they must believe it; they must be consistent in their message. We sometimes call this "practicing what you preach". I think that a teacher must tell an authentic story, which includes practicing what we teach.

There is, of course, another sense in which teachers are liars. Computer science is a wide and deep discipline. At the beginning of their studies, most students are not ready to hear or understand the full breadth and depth of computing. So we simplify the story, telling just the part of the truth that students are ready to understand, laying the groundwork that prepares them to go wider and deeper. Sometimes, we have to oversimplify, telling a story that is not strictly true, so that students will learn what they need to know now, preparing them for a more accurate story later.

Anyone who has taught any real programming language to CS1 students -- C++ and Java have been the most popular over the last 10-12 years -- knows what I mean. If I try to tell a 100% accurate story about Java constructors or access modifiers to my CS1 students, most will learn nothing at all. The story is too complex for their world view of programs. So I tell a circumscribed, simplified, and technically inaccurate story, as a means to help them learn.

We call these stories "simplifications", maybe even "oversimplifications", or more grandiosely "abstractions" -- but rarely do we call them lies. Yet they are incomplete stories that often fail when they are examined closely or stretched beyond their limits. They serve a purpose, and soon the student is ready for a more complete story, which we then tell. The student's world view grows. What she knows and believes comes a bit more into line with what I (and perhaps the textbook author) know and believe about the world, which usually reflects what the community of computer science scholars believes to be the most accurate story we can tell.

Of course, I don't want to leave students only with my view of the world; I want to help them develop the faculties they need to create their own viewpoint, to analyze new data and new ideas critically. But that is a long-term project, not something that is likely to happen in their earliest courses.

Note that this way of thinking makes the teacher's own authenticity even more important. Students soon realize that they are learning simplifications and abstractions. When we are authentic and consistent, when we practice what we teach, students can trust us and believe that our simplifications are worthwhile stepping stones. Then our stream of simplifications looks like unfolding truth, not just convenient falsehoods meant to fill class time.

Godin doesn't directly address instructors, but many of his lessons sound as if he knows our plight. Consider:

Some marketers focus so hard on the facts of their offering that they forget to tell a story at all, and then wonder why the fail.

And:

... there's a lot of teaching for marketers to do. Alas, there is no time to do it. [There are too many facts to communicate, and too many competitors for your audience's attention.] As a result, people pick and choose. Everyone will not listen to everything.

All Marketers Are Liars is another short and sweet book, under 180 pages. It is better written than Let's Kill Dick and Jane. Godin practices what he teaches, and that makes for a good story.

Or is that just the lie I tell myself after Godin tells me his story?

Sponsored outlets in the walkways of the concourses:

You and your laptop may sigh with relief now.

and

Sharing the outlet is good business karma.

The sponsor in this case is Chase, The Bank Formerly Known as Chase Manhattan and later as JP Morgan Chase. Each outlet plate has a blue Chase banner running down the wall from about eye level right down to the pair of outlets. The banners caught my eye, so I guess they worked. Eventually the gimmick will wear out its novelty -- perhaps it already has for other flyers, or elsewhere in the country; I don't fly often -- but I thought it was cute. Funny how changes in technology have made something as mundane as an open outlet so valuable!

Oh, and thanks to cashing in some very old, expiring frequent flyer miles, I flew first class for the first time in a long time, from Indianapolis to John Wayne/Orange County. It wasn't quite like the Seinfeld episode in which Jerry and Elaine experience the different sides of traveling first class and coach, but it was very, very nice. A good addition to my vacation.

No, I've not become homicidal. That is the title of a recent book about the Open Court Publishing Company, which according to its subtitle "fought the culture of American education" by trying to change how our schools teach reading and mathematics. Blouke Carus, the creator of Open Court's reading program, sought to achieve an enviable goal -- engagement with and success in the world of great ideas for all students -- in a way that was beholden to neither the traditionalist "back to basics" agenda nor the progressivist "child-centered" agenda. Since then, the reading series has been sold to McGraw-Hill.

Thanks to the creator of the TeachScheme! project, Matthias Felleisen, I can add this book to my list of millions. He calls Let's Kill and Dick and Jane "TeachScheme! writ large". Certainly there are differences between the K-8 education culture and the university computer science culture, but they share enough commonalities to make reform efforts similarly difficult to execute. As I have noted before, universities and their faculty are a remarkably conservative lot. TeachScheme! is a principled, comprehensive redefinition of introductory programming education. In arguing for his formulation, Felleisen goes so far as to explain why Structure and Interpretation of Computer Programs -- touted by many, including me, as the best CS book ever written -- is not suitable for CS 1. (As much as I like SICP, Matthias is right.)

But TeachScheme! has not succeeded in the grand way its implementors might have hoped, for many of the reasons that Open Court's efforts have come up short of its founders' goals. Some of the reasons are cultural, some are historical, and some are probably strategic.

The story of Open Court is of immediate interest to me for our state's interest in changing K-12 math and science education in a fundamental way, a reform effort that my university has a leading role in, and which my department and I have a direct interest in. We believe in the need for more and better computer scientists and software developers, but university CS enrollments remain sluggish. Students who are turned off to science, math, and intellectual ideas in grade school aren't likely to select CS as a major in college... Besides, like Carus, I have a great interest in raising the level of science and math understanding across the whole population.

This book taught me a lot about what I had understood only incompletely as an observer of our education system. And I appreciated that it avoided the typical -- and wrong -- conservative/liberal dichotomy between the traditional and progressive approaches. America's education culture is a beast all its own, essentially anti-intellectual and exhibiting an inertia borne out of expectations, habit, and a lack of will and time to change. Changing the system will take a much more sophisticated and patient approach than most people usually contemplate.

Though I have never developed a complete curriculum for CS 1 as Felleisen has, I have long aspired to teaching intro CS in more holistic way, integrating the learning of essential tools with higher-level design skills, built on the concept of a pattern language. So Open Court's goals, methods, and results all intrigue me. Here are some of the ideas that caught my attention as I read the story of Open Court:

• On variety in approach:

  A teacher must dare to be different! She must pull away from monotonous repetition of, 'Today we are going to write a story.' Most children view that announcement with exactly what it deserves, and there are few teachers who are not aware of what the reactions are.

  s/story/program/* and s/children/students/* to get a truth for CS instructors such as me.

• A student is motivated to learn when her activities scratch her own itch.
• Teaching techniques that may well transfer to my programming classroom: sentence lifting, writing for a real audience, proofreading and revising programs, and reading good literature from the beginning.
• On a curriculum as a system of instruction:

  The quality of the Open Court program was a substantive strength and a marketing weakness. It required teachers to be conversant with a variety of methods. And the program worked best when used as a system... Teachers accustomed to trying a little of this and a little of that were likely to be put off by an approach that did not lend itself to tinkering.

  I guess I'm not the only person who has trouble sticking to the textbook. To be fair to us tinkerers, systematic integrated instructional design is so rare as to make tinkering a reasonable default stance.

• On the real problem with new ideas for instruction:

  Thus Open Court's usual problem was not that it contradicted teachers' ideology, but that it violated their routine.

  Old habits dies hard, if at all.

• In the study of how children learn to comprehend text, schema theory embodied the "idea that people understand what they read by fitting it into patterns they already know". I believe that this is largely true for learning to understand programs, too.
• Exercising existing skills does not constitute teaching.
• Quoting a paper by reading scholars Bereiter and Scardamalia, the best alternative model for a school is

  ... the learned professions ...[in which] adaptation to the expectations of one's peers requires continual growth in knowledge and competence.

  In the professions, we focus not only on level of knowledge but also on the process of continuously getting better.

• When we despair of revolutionary change:

  There are circumstances in which it is best to package our revolutionary aspirations in harmless-looking exteriors.... We should swallow our pride and let [teachers] think we are bland and acceptable. We should fool them and play to their complacent pieties, But we should never for a moment fool ourselves.

  Be careful what you pretend to be.

• Too often, radical new techniques are converted into "subject matter" to be added to the curriculum. But in that form they usually become overgeneralized rules that fail too often to be compelling. More insidious is that this "makes it possible to incorporate new elements into a curriculum without changing the basic goals and strategies of the curriculum". Voilá -- change with no change.

  Then we obsess about covering all the material, made harder by the inclusion of all this new material.

  I've seen this happen to software patterns in CS classrooms. It was sad. I usually think that we elementary patterns folks haven't done a good enough job yet, but Open Court's and TeachScheme!'s experiences do not encourage me to think that it will be easy to do well enough.

• On the value of a broad education: This book tells of how the people at Open Court who were focused exclusively on curriculum found themselves falling prey to invalid plans from marketers.

  In an academic metaphor, [Open Court's] people had been the liberal-arts students looking down on the business school. But now that they needed business-school expertise, they were unable to judge it critically.

  Maybe a so-called "liberal education" isn't broad enough if it leaves the recipient unable to think deeply in an essential new context. In today's world, both business and technology are essential components of a broadly applicable education.

• On the need for designing custom literature suitable for instruction of complete novices:

  Teaching any skill requires repetition, and few great works of literature concentrate on long "e".

  My greatest inspiration in this vein is the Suzuki literature developed for teaching violin and later piano and other instruments. I've experienced the piano literature first hand and watched my daughters work deep into the violin literature. At the outset, both use existing works (folk tunes, primarily) whenever appropriate, but they also include carefully designed pieces that echo the great literature we aspire to for our students. As the student develops technical skill, the teaching literature moves wholly into the realm of works with connection to the broader culture. My daughters now play real violin compositions from real composers.

• But designing a literature and curriculum for students is not enough. Ordinary teachers can implement more aggressive and challenging curricula only with help: help learning the new ideas, help implementing the ideas in classroom settings, and help breaking the habits and structures of standing practice. Let's Kill Dick and Jane is full of calls from teachers for more help in understanding Open Court's new ideas and in implementing them well in the face of teachers' lack of experience and understanding. Despite its best attempts, Open Court never quite did this well enough.

  TeachScheme! is a worthy model in this regard. It has worked hard to train teachers in its approach, to provide tangible support, and to build a community of teachers.

  In my own work on elementary patterns, my colleague and friend Robert Duvall continually reminds us all of the need for providing practical support to instructors who might adopt our ideas -- if only they had the instructional tools to make a big change in how they teach introductory programming.

• ... which leads me to a closing observation. One of the big lessons I take from the book is that to effect change, one must understand and confront issues that exist in the world, not the the issues that exist only in our idealized images of the world or in what are basically the political tracts of activists.

  In an odd way, this reminds me of Drawing on the Right Side of the Brain, with its precept that we should draw what we see, not what we think we see.

Let's Kill Dick and Jane is a slim volume, a mere 155 pages, and easy to read. It's not perfect, neither in its writing nor in its analysis, but it tells an important story well. I recommend it to anyone with aspirations of changing how we teach computer science to students in the university or high school. I also recommend it to anyone who is at all interested in the quality of our educational system. In a democracy such as the U.S., that should be everyone.

(The sixth stop in the Running on the Road series. The first five were Allerton Park, Illinois, Muncie, Indiana, Vancouver, British Columbia, St. Louis, Missouri, Houston, Texas, and Carefree, Arizona.)

I tend to write these reports about running in a big city that others might visit, or a hot tourist spot, or at least a conference location, that some readers of my blog may care about. But this is more like my report on visits to my alma mater in Muncie, Indiana. It is about running in my high school hometown of Greenfield, Indiana. I didn't live in Greenfield for very long -- for four years of high school, and then summers during my college years -- but in many ways it still feels like home. I'm finishing up a few days back in Greenfield for a high school reunion, and I did something I never did when I lived here all those years ago: I ran.

I did not run at all, really, until I was in graduate school. Sure, there were occasional attempts at a few miles here and there, and a bit of time on the track in physical education classes, but I never got over the hump. Every run seemed less enjoyable than it should have been, and I never got past the feeling that I wasn't cut out to run.

So running this weekend gave me a different perspective on my hometown than I had ever had before, on the pavement at dawn, seeing buildings and scenery and signs pass by me from eye level. When I add this effect to the sense of change I felt after having been gone from town almost completely for eleven years and and nearly so for twenty, I experienced an mixture of déja vu and jamais vu unlike any before. For hours. While maxing out my legs at the beginning of marathon training. Not ordinary runs at all. The unusual sensation of time fits very well with attending a 25-year high school reunion and with recently reading Alan Lightman's book.

I used my time own the road to survey the changes that have happened in Greenfield in the last decade. I recall it as a town of 15,000 or so folks, most with rural and small-town roots. Its official population back in 1980 must have been much less, as the 1990 census shows only about 12,000 people, but the outlying rural areas were then beginning to attract people from bigger cities in search of inexpensive land. Unofficially, the population these days must be closer to 30,000, and one can see that in the explosive growth of the town to the north and east. One big change I notice as I visit local stores and restaurants and as I run through town is much greater diversity. When I lived here, Greenfield and its entire county were almost 100% white, but now I see Asian immigrants, African Americans, and especially Latinos everywhere. The result is more plentiful choices of food for the palate and a richer set of accents for the ear.

Sightseeing in one's own hometown is a great way to run. I encourage it to those of you who ever have the chance.

Other than running around town on city and country roads, I can report one neat development: the beginnings of a recreation route called the Pennsy Trail. This trail parallels Old National Road (U.S. 40) along the former Pennsylvania Railroad line just south of Greenfield's main street. It crosses Brandywine Creek, which is the presumed site of poet and Greenfield native James Whitcomb Riley's ol' swimmin' hole. Right now, the trail isn't much, running only 3 miles or so to the east of downtown Greenfield, but eventually the Pennsy Trail will connect westward to a network of trails in central Indiana, and perhaps be a link in the National Road Heritage Trail, which will follow U.S.40 across Indiana's breadth. As a runner, I greatly appreciate clean, marked, metered trails that offer peace, natural scenery, and even occasional services such as water fountains and toilet facilities. They are also a great resource for the citizens of the community, a sign that the community is thinking about the quality of life it offers citizens and visitors alike.

Now I am off for a couple of days running in Plainfield, a city also on the Old National Road but on the west side of Indianapolis. Plainfield also has a nice trail system connecting its parks from north to south, which I will surely patronize. After that I'll do one run in Santa Ana, California, and a couple in San Diego. I probably will not write Running on the Road reports for Plainfield or Santa Ana, but I do have some raw material for a report on San Diego, from my three trips for OOPSLA 2005. San Diego is a beautiful place to run, and I look forward to being there just for fun.