To soothe my bruised ego, yesterday evening I did a little light blog reading. Among the articles that caught my attention was Philip Greenspun's Why I love teaching flying more than software engineering. People learning to fly want to get better; I'm guessing that most of them want to become as good as they possibly can. (Just like this guy wanted to make as good a product as possible.) Philip enjoys teaching these folks, more so than teaching students in the area of his greatest expertise, computing, because the math and computing students don't seem to care if they learn or not.
I see students who will work day and night until they become really good software developers or really good computer scientists, and the common thread through their stories is an internal curiosity that we can't teach. But maybe we can expose them to enough cool problems and questions that one will kick their curiosity into overdrive. The ones who still have that gear will do the rest. Philip worries that most students these days "are satisfied with mediocrity, a warm cubicle, and a steady salary." I worry about this, too, but sometimes wonder if I am just imagining some idyllic world that never has existed. But computer science is so much fun for me that I'm sad that more of our students don't feel the same joy.
While reading, I listened to Olin Shivers's talk at Startup School 2005, "A Random Walk Through Startup Space" (mp3). It had been in my audio folder for a while, and I'm glad I finally cued it up. Olin gives lots of pithy advice to the start-up students. Three quotes stood out for me yesterday:
Scientific progress advances in units of courage, not intelligence.
... to start a business, you've got to have a high tolerance for feeling like a moron all the time.
And how should you greet failure when you're staring it in the face?
Thank you for what you have taught me.
Some days, I walk out of the classroom and feel, Man, I am good. Today was not one of those days. On days like today, I walk out the classroom thinking alternately, "Did I really just do that to my students?" and "What a rotten day."
Such days don't usually "just happen". (Well, except when my biorhythms are out of whack...) I think I can trace today's not-so-good performance to a few things:
Fortunately for my students, I don't have too many days like today. Besides, it's good for the universe to remind me every so often that I'm not that good. Keeps me humble.
I haven't had a chance to write in over a week, but a busy week it has been. My last post foreshadowed the move of my department office to a new home, in an old building on campus that has been renovated into an "innovative teaching and technology center". That name actually sets a higher standard than the building can live up to, but it will be a good home for us.
Last week, we began moving the department office to its new home, to make space for a computer lab. I suppose that we didn't technically have to move the department head's office yet, because the old office isn't need for something else yet. but anyone who has ever been at a university knows that heads, deans, and the like depend on their administrative staff too much to be separated from them. In this era of continuous electronic communication, I could probably survive better than most administrators from the past, but it would make an already challenging job all the more difficult to be two buildings away from the department secretary. So I moved, too, if only the working set of my office for now.
Not that I didn't have good reason to want to move. The university's provost, after taking a tour of the new building during construction, made a point of telling me that my office may have the best view on campus. Here is a digital snapshot looking out my window toward the southwest on a recent sunny day:
Here's a lower-quality picture of the view toward the northwest. The campanille serves as nice reference point:
I don't have the highest-quality digital camera, but I've done the best I can to reproduce my view. The glare off my windows makes it tough to get good shots from all angles. But, quoting Sidra from Seinfeld, I can say that these images "are real, and they are spectacular". Either karma is looking out for me, or I have simply lucked into one of the best offices on campus. I should probably be nervous that my provost, my dean, and nearly every other administrator on campus know about my office and view, but I've been too busy withe the business of the department to worry.
Of course, the construction in the rest of the building is still being completed, and there are warts to fix. For example: When I came into the office last Friday morning, the temperature in my office was 63 degrees Fahrenheit; this morning, it was 83 degrees Fahrenheit. After over eleven hours with the windows open and the door open to permit circulation through the department office, I have the temp down to 78 degrees. But I'm sure that this is the sort of kink we can work out over the next few months. (Let's hope so. With windows and western exposure, the summer could proved quite warm otherwise!)
Computer science happens for me these days only in fits and spurts, mostly short ones when I decide to find time to read by downgrading some other task's priority. This summer is my next real chance to do real computing. I've been learning a lot this year, but I hope to put that learning to good use in the future by managing times and tasks more carefully.
If you've read my blog for long, you know that I like a good metaphor. We can often learn something useful about one system by considering it as another kind of system and seeing what kind of questions this new conception leads us to ask.
"Software engineering" is a metaphor, even if many folks take it for granted as reality. I've never been all that fond of the metaphor, though we certainly can learn something about how to develop software by considering how engineers make things. But my experience with commercial engineering projects on university campuses has never felt like how I do or might build software.
My latest experience -- with the renovation of an old building on campus as a new home for my department -- has illustrated yet again why we should not limit ourselves to engineering as the model for how we make software.
This building project is now over six months late. Each time the schedule is adjusted, it seems to fall behind again within the month. Communication among the various units responsible for, and affected by, project has been abysmal. Changes were made to plans, but these changes did not propagate to everyone who needed to know and as a result work plans were often out of sync. Sometimes, folks knew about a change but had no incentive to find out how the change affected what they should be doing -- so they didn't.
My favorite example of this was when a service closet was converted to a server room for my department. The change was made in conjunction with building architects, and the updated drawings for the building now showed a "server room". At least some of folks responsible for building infrastructure were aware of the change, but they either assumed that the change didn't affect them or figured they didn't want to know how it would. Plans proceeded as they were, with no provision made for the necessary cooling or power to the room. As the time came for us to move in, we increasingly pressed for these changes to the room, which would now be costlier to implement, both in time and money.
I know, this is only an anecdote, one experience by one person with one project. It hardly serves as a suitable logical basis for arguing that a seemingly useful idea should be discarded. But this experience is representative others I have had, and also representative of experiences had by many others on this and other campuses with building construction and renovation. It is a now banal joke on campus that we should add months to each target date we are given for the completion of projects.
Don't get me wrong. These are not bad people. I think all are trying to do their jobs well under demanding circumstances. But as Mary Poppendieck reported in a widely read paper on lean construction, the system doesn't work in a way that makes smooth, timely projects all that likely. Projects are complicated, plans are tightly coupled, and pipelines are sensitive to small changes in expectation. That's just how the world really is.
This is one of the dangers inherent in metaphor: unreality. It is easy for us in software to idealize other disciplines and how they work. One result is that we beat ourselves up for how we could do better is only we were more like "them", for some broad spectrum of thems. Architecture -- isn't it just dreamy? Engineering -- tough, rigid, clean, controlled. But we need to make metaphors with our eyes carefully tuned to how the world really is in those other disciplines, not only the ideas but the daily practices and experiences. Otherwise, we are bound to create unrealistic expectations for how we do what we do, and how well we do it.
And ultimately we lose out on the learning to be had from the metaphor, because we will miss the opportunity to ask ourselves the questions that will help us to understand better what we do.
Education is an admirable thing,
but it is well to remember from time to time
that nothing worth knowing can be taught.
-- Oscar Wilde
Recently I have been having an ongoing conversation with one of my colleagues, a senior faculty member, about teaching methods. This conversation is part of a larger discussion of the quality of our programs and the attractiveness of our majors to students.
In one episode, we were discussing the frequency with which one quizzes and exams the class. Some of our math professors quiz almost daily, and even some CS professors give substantial quizzes every week. My colleague thinks is a waste of valuable class time and a disservice to students. I tend to agree, at least for most of our CS courses. When we assess students so frequently for the purposes of grading, the students become focused on assessment and not on the course material. They also tend not to think much about the fun they could be having writing programs and understanding new ideas. They are too worried about the next quiz.
My colleague made a much stronger statement:
Students are paying for content.
In an interesting coincidence, when he said this I was preparing a class session in which my students would do several exercises that would culminate in a table-driven parser for a small language. We had studied the essential content over the previous two weeks: first and follow sets, LL(1) grammars, semantic actions, and so on.
I don't think I was wasting my students time or tuition money. I do owe them content about compilers and how to build them. But they have to learn how to build a compiler, and they can't learn that by listening to me drone on about it at the front of the classroom; they have to do it.
My colleague agrees with me on this point, though I don't think he ever teaches in the way I do. He prefers to use programming projects as the only avenue for practice. Where I diverge is in trying to help students gain experience doing in a tightly controlled environment where I can give almost immediate feedback. My hope is that this sort of scaffolded experience will help them learn and internalize technique more readily.
(And don't worry that my students lack for practical project experience. Just ask my compiler students, who had to submit a full parser for a variant of Wirth's Oberon-0 language at 4 PM today.)
I think that our students are paying for more than just content. If all they need is "dead" content, I can give them a book. Lecture made a lot of sense as the primary mode of instruction back when books were rare or unavailable. But we can do better now. We can give students access to data in a lot of forms, but as expert practitioners we can help them learn how to do things by working with them in the process of doing things.
I am sympathetic to my colleague's claims, though. Many folks these days spend far too much time worrying about teaching methodology than about the course material. The content of the course is paramount; how we teach it is done in service of helping students learn the material. But we can't fall into the trap of thinking that we can lecture content and magically put it into our students' heads, or that they can magically put it there by doing homework.
This conversation reminded me of a post on learning styles at Tall, Dark, and Mysterious. Here is an excerpt she quotes from a cognitive scientist:
What cognitive science has taught us is that children do differ in their abilities with different modalities, but teaching the child in his best modality doesn't affect his educational achievement. What does matter is whether the child is taught in the content's best modality. All students learn more when content drives the choice of modality.
The issue isn't that teaching a subject, say, kinesthetically, doesn't help a kinesthetic learner understand the material better; the issue is that teaching material kinesthetically may compromise the content.
Knowledge of how to do something sometimes requires an approach different from lecture. Studio work, apprenticeship, and other forms of coached exercise may be the best way to teach some material.
Finally, that post quotes someone who sees the key point:
Perhaps it's more important for a student to know their learning style than for a teacher to teach to it. Then the student can make whatever adjustments are needed in their classroom and study habits (as well as out of classroom time with the instructor).
In any case, a scientist or a programmer needs to possess both a lot of declarative knowledge and a lot of procedural knowledge. We should use teaching methods that best help them learn.
There's a title I never had planned for a blog entry.
This isn't really a running post, but if I were not a runner, then it would never have happened. Then again, if there had never been a 09/11, it probably wouldn't have happened, either.
When I go to conferences, I pack for running. For the past couple of years, I have taken powered Gatorade and an empty water bottle with me. Just add water, I have the liquid I need to recover from longer runs. The Gatorade turns out to be a nice drink even on mornings when I don't run -- conferences often don't serve anything but coffee in the morning, and sports drink is low-calorie and high vitamins and minerals.
I pack the powder in a plastic container that seals tight, to keep the powder in and the moisture out. On my trip to Houston, I took tropical punch-flavored powder.
Well, my friends at the TSA must have conducted a thorough search of my bags on the way bag from Houston. When I got home, there was little red powder everywhere, but especially in my running shoes and clothes. I found the plastic container, whose lid had not been put back on tightly. It was in a large ziploc baggy that wasn't zipped 100% either. So the search may have been thorough, but it was not all that careful.
I grumbled a bit about the misfortune, shook my clothes and shoes out carefully, and forgot about it.
Until this morning. When I finished my run, I was changing in the locker room when I noticed that my socks were pink at the ankles. When I got the shoes off, I saw that the socks were mottled pink all over, especially the soles. I must not have gotten all of the powder out of my shoes after all. Now a pair of good running socks is stained irreversibly with red dye #2.
I suppose that I should have done something more to be sure that my shoes were powder-free, but it just didn't occur to me.
Thanks, TSA. Thanks, Al Qaeda.
Back when I started this blog, I commented that "the hard drive of every computer I've ever had is littered with little snippets and observations that I would have liked to make available to someone, anyone, at the time." At the time, I thought that I might draw on some of my old writings for my blog. That hasn't happened, because I've usually either had something new to write about that interested or had no time to blog at all.
Apparently, not all of my old writings ended up in dead files somewhere. While I was getting ready for my compiler class today, I looked over the lecture notes from the corresponding session the last time I taught this course. The date was November 4, 2003, and I had just returned from OOPSLA in Anaheim. I was excited about the conference, I'm sure, as I always am, and used part of my first class back to share some of what I had learned at the conference. (I wouldn't be surprised if part of my motivation in sharing was avoid diving head-first back into semantic analysis right away... :-)
My lecture notes for that day looked a lot like a set of blog entries! So it seems that my students were unwitting, though not unwilling, audience for my blogging before this blog began.
I enjoyed re-reading one of these OOPSLA'03 reports enough that I thought I'd polish it up for a wider audience. Here is an excerpt from my compiler lecture notes of 11/04/03, on David Ungar's keynote address, titled "Seven Paradoxes of Object-Oriented Programming Languages". I hope you enjoy it, too.
His abstract lists seven paradoxes about language that he thinks make designing a good programming language so difficult. He titled and focused his talk on object-oriented languages, given his particular audience, but everything he said applies to languages more generally, and indeed to most design for human use. His points are about language design, not compiler design, but language design has a profound effect on the implementation of a compiler. We've seen this at a relatively low level when considering LL and LR grammars, and it applies at higher levels, too.
He only addressed three of his paradoxes in the talk, and then in a more accessible form.
1. Making a language better for computers makes it worse for people, and vice versa.
He opened with a story about his interview at MIT when he was looking for his first academic position. One interviewer asked him to define 'virtual machine'. He answered, "a way to give programmers good error messages, so that when there weren't any error messages the program would run successfully". The interviewer said, "If you believe that, then we have nothing more to talk about it." And they didn't. (He got the offer, but turned it down.)
A programming language has to be mechanistic and humanistic, but in practice we let the mechanistic dominate. Consider: write a Java class that defines a simple stack of integers. You'll have to say int five times -- but only if you want 32-bit integers; if you want more or less, you need to say something else.
The machines have won! How can we begin to design languages for people? We first must understand how they think. Some ideas that he shared from non-CS research:
Our programming languages must reflect a consciousness of abstraction for even the simplest ideas; in C++ and Java, these include const, final, and ==. (A final field in Java cannot be modified, but its value can change if it is a mutable object...)
If class-based languages pose such problems, what is the alternative? How about an instance-based language? One example is Self, a language designed by Ungar and his colleagues at Sun. But instance-based languages pose their own problems...
2. The more concepts we add to a language, the less general code that we write.
He opened with a story about his first big programming assignment in college, to write an assembler. He knew APL best -- a simple language with few concepts but powerful operators. He wrote a solution in approximately 20 lines of code. How? By reading in the source as a string and then interpreting it.
Some of his PL/1-using classmates didn't get done. Some did, but they wrote hundreds and hundreds of lines of code. Why? They could have done the same thing he did in APL -- but they didn't think of it!
But why? Because in languages like Fortran, PL/1, C, Java, etc., programs and data are different sorts of things. In languages like APL, Lisp, Smalltalk, etc., there is no such distinction.
Adding more concepts to a language -- such as distinguishing programs from data -- impoverish discourse because they blind us, create a mindset that is focused on concepts, not problems.
Most OOPs adopt a classes-and-bits view of objects, which encourages peeking at implementation (getters/setters, public/private, ...). Could create a better language that doesn't distinguish between data and behavior? Self also experiments with this idea, as do Smalltalk and Eiffel.
Adding a feature to a language solves a specific problem but degrades learnability, readability, debuggability -- choosing what to say. (Why then do simpler languages like Scheme not catch on? Maybe it's not a technical issue but a social one.)
What is an alternative? Build languages with layering -- e.g., Smalltalk control structures are built on top of blocks and messages.
3. Improving the type system of a language makes the type system worse.
This part of Ungar's talk was more controversial, but it's a natural application of his other ideas. His claim: less static type checking implies more frequent program change, implies more refactoring, implies better designs.
So what? We can use these ideas to understand our languages and the ways we program in them. Consider Java and some of the advice in Joshua Bloch's excellent book Effective Java.
What went wrong? Lack of consciousness of abstraction. Richer is poorer (constructor distinctive from message send).
What went wrong? Better types are worse. Why doesn't the type system check this?
Ambiguity communicates powerfully. We just have to find a way to make our machines handle ambiguity effectively.
[end of excerpt]
As with any of my conference reports, the ideas presented belong to the presenter unless stated otherwise, but any mistakes are mine.
The rest of this lecture was a lot like my other conference-themed blog entries. Last week, I blogged about the Python buzz at SIGCSE; back in late 2003 I commented on the buzz surrounding the relatively new IDE named Eclipse. And, like many of my conference visits, I came back with a long list of books to read, including "Women, Fire, and Dangerous Things", by George Lakoff, "The Innovator's Dilemma", by Clayton Christensen, and "S, M, L, XL", by Rem Koolhaas and Bruce Mau.
Some things never change...
I was able to stay at SIGCSE only through the plenary talk Friday morning, and so there won't be a SIGCSE Day 2 entry. But I can summarize a few ideas that came up over the rest of Day 1 and the bit of Day 2 I saw. Consider this "SIGCSE Days 1 and 1.15".
Broadening the Reach of CS
I went to a birds-of-a-feather session called "Innovative Approaches to Broadening Computer Science", organized by Owen Astrachan and Jeffrey Forbes of Duke. I was surprised by the number and variety of schools that are creating new courses aimed at bringing computing to non-computer scientists. Many schools are just beginning the process, but we heard about computing courses designed specially for arts majors, psychology majors, and the more expected science and engineering majors. Bioinformatics is a popular specialty course. We have an undergraduate program in bioinformatics, but the courses students take at the beginning of this program are currently traditional programming courses. My department recently began discussions of how to diversify the entry paths into computing here, with both majors and non-majors in mind. It's encouraging to see so many other schools generating ideas along these lines, too. We'll all be able to learn from one another,
Not quite, but close. Henry Walker and David Levine presented a paper titled "XP Practices Applied to Grading". David characterized this paper as an essay in the sense resurrected by the essays track at OOPSLA. I enjoy SIGCSE talks that reflect on practices. While there wasn't much new for me in this talk, it reminded Jim Caristi and me of a 1998 OOPSLA workshop that Robert Biddle, Rick Mercer, and I organized called Evaluating Object-Oriented Design. That session was one of those wonderful workshops where things seem to click all day. Every participant contributed something of value, and the contributions seemed to build on one another to make something more valuable. I presented one of my favorite patterns-related teaching pieces, Using a Pattern Language to Evaluate Design. What Jim remembered most vividly from the workshop was the importance in the classroom of short cycles and continuous feedback. It was good to see CS educators like Henry and Dave presenting XP practices in the classroom to the broader SIGCSE community.
ACM Java Task Force
Over the last two-plus years, the ACM Java Task Force has put in a lot of time and hard work designing a set of packages for use in teaching Java in CS1. I wonder what the ultimate effect will be. Some folks are concerned about the graphics model that the task force adopted. ("Back to Java 1.0!" one person grumbled.) But I'm thinking more of the fact that Java may not last as the dominant CS1 language much longer. At last year's SIGCSE one could sense a ripple of unease with Java, and this year the mood seemed much more "when...", not "if...". Rich Pattis mentioned in his keynote lecture that he had begun teaching a new CS1 language every five years or so, and Java's time should soon be up. He didn't offer a successor, but my read of the buzz at SIGCSE is that Python is on the rise.
Computer Science in K-12 Education
The second day plenary address was given by a couple of folks at the Computer Science Teachers Association, a group affiliated with the ACM that "supports and promotes the teaching of computer science and other computing disciplines" in the K-12 school system. I don't have much to say about their talk other than to note that there a couple of different issues at play. One is the teaching of computer science, especially AP CS, at the pre-university level. Do we need it? If so, how do we convince schools and taxpayers to do it right? The second is more general, the creation of an environment in which students want to study math, science, and technology. Those are the students who are in the "pipeline" of potential CS majors when they get to college. At first glance, these may seem like two separate issues, but they interconnect in complicated ways when you step into the modern-day high school. I'm glad that someone is working on these issues full-time, but no one should expect easy answers.
In the end, Rich Pattis's talk was the unchallenged highlight of the conference for me. For all its activity and relatively large attendance (1100 or so folks), the rest of the conference seemed a bit low on energy. What's up? Is the discipline in the doldrums, waiting for something new to invigorate everyone? Or was it just I who felt that way?
If the buzz is accurate, Python may be a successor. The conference program included a panel on experiences teaching Python to novices, including John Zelle and Mark Guzdial, who have written the two texts currently available. My publisher friend Jim Leisy of Franklin, Beedle was very high on Zelle's book and the adoptions they've picked up in the last few months. The range of schools now using Python in at least one track of their intro courses ranges from small private schools all the way to MIT.
Heck, I got home from SIGCSE and "PYTHON" even showed up as a solution in the local newspaper's Saturday Jumble!
All in all, I think I prefer Ruby, both for me and for beginners, but it is behind Python in the CS education life cycle. In particular, there is only one introductory level book available right now, Chris Pine's Learn To Program. Andy Hunt from the Pragmatic Bookshelf sent me a review copy, and it looks good. It's not from the traditional CS1 textbook mold, though, and will face an uphill battle earning broad attention for CS1 courses.
In any case, I welcome the return to a small, simple, language for teaching beginners to program. Whether Ruby or Python, we would be using an interpreted language that is of practical value as a scripting language. This has great value for three audiences of student: non-majors can learn a little about computing while learning scripting skills that they can take to their major discipline; folks who intend to major in CS but change their minds can also leave the course with useful skills; and even majors will develop skills that are valuable in upper-division courses. (You gotta figure that they'll want to try out Ruby on Rails at some point in the next few years.)
Scripting languages pose their own problems, both in terms of language and curriculum. In particular, you need to introduce at least one and maybe two systems languages such as Java, C, or C++ in later courses, before they are needed for large projects. But I think the trade-off will be a favorable one. Students can learn to program in an engaging and relatively undistracting context before moving on to bigger issues. Then again, I've always favored languages like Smalltalk and Scheme, so I may not be the best bellwether of this trend.
Anyway, I left SIGCSE surprised to have encountered Python at so many turns. Maybe Java will hang on as the dominant CS1 language for a few more years. Maybe Python will supplant it. Or maybe Python will just be a rebound language that fills the void until the real successor comes along. But for now the buzz is notable.
My Running on the Road series has lain dormant since last year's SIGCSE. It's not that I haven't been running on the road... I've had some great runs in Carefree, Arizona; San Diego (twice); Plainfield, Indiana; Portland, Oregon; and Knoxville, Tennessee. But some of these runs weren't ones that I wanted a long-term record of, and others came at times that found me so busy that I never got around to blogging. For one, Carefree, I'd like to write to something more than a routine few paragraphs, and so I saved it for this year's ChiliPLoP.
This week at SIGCSE I had a chance to run in downtown Houston, Texas. I've not spent much time in Texas, and both major visits have been for SIGCSE. For a midwesterner, Houston is a great place to visit in February or early March. It's generally cold at home, and Houston is not yet rainy or oppressively hot and humid as it will be later in the year.
Many downtown conferences are not ideal for a runner, though, because some downtowns are concrete jungles. Houston is like that. I'm sure there are some scenic runs out in the neighborhoods and suburbs that ring the city, but they are hard to get to you easily, because Houston is a town for drivers. Despite this, I was pleasantly surprised to cobble together a nice little loop around downtown Houston that met my needs.
The conference was at the Hilton Americas, but I stayed 2/3 a mile away at the Club Quarters, which is a members-oriented hotel. When I booked my reservation, I did not realize that this hotel is right in the center of Houston's downtown. I studied the local map I was given at check-in and found what looked to a big rectangle around the perimeter of the area that was just the right size: small enough that I could run multiple loops to assemble runs of different lengths and always be within reach of my hotel (in case nature calls and won't take 'no' for an answer), but large enough that I didn't feel like I was running laps on a track.
The loop was bounded by Dallas on the south, Crawford on the east, Preston on the north, and Bagby on the west. This route turned out to be nearly ideal as it took me by most of the landmarks of the downtown area. I saw the old county courthouse (first picture above) and Houston City Hall (picture on left). Near the northeast corner of my loop, I passed the second oldest church in Houston, the Church of the Annunciation (picture below), and one of the newer ball parks in major league baseball, Minute Maid Park, home of the Astros (pictured near the bottom of the post). These landmarks are across the street from each other, which may be convenient some game days! Near the southwest corner of the loop I ran past the scenic attraction Downtown Aquarium-Houston.
For both of my runs, I also ran from the Club Quarters south to Dallas and then back up Main to Capitol. This access route paralleled Houston's light rail line.
MapQuest tells me that my loop is about 2.9 miles, plus 0.3 miles for parts of the hotel access. But my instincts and body tell me that I was running closer to 3.0 miles total for the whole circuit. On Wednesday, I ran the three passes for a total of about nine miles, and on Thursday twice for about six.
As with most big cities, the time of a run has a large effect on how traffic a runner must deal with. My first morning out, I didn't start until almost 7:00 AM, and traffic was heavy on nearly every street. On my second morning, I hit the pavement at about 5:45 AM and found mostly deserted streets. As a result, I was able to cross on most red lights without affecting traffic or endangering myself.
Running in morning rush hour traffic the first day had two effects on my run that I hadn't anticipated. First was on my elapsed time. I ran for 75 minutes, but I was on the road for 98! I hadn't considered that while I was stopped waiting for a traffic light to change that the earth continued to revolve beneath me. This surprise left me running late for my heads workshop the first day.
Second was on my speed. Because I was stopping every few blocks for a light, I was starting up every few blocks. It's natural for me to take off just a wee bit faster than the pace I plan to maintain, and besides all of those little breathers kept me a bit fresher than I would have felt over nine miles of non-stop running. This surprise left me a bit sorer than I would ordinarily be after an easy run, much like a track workout does. Given that I don't have much experience running in town, I am not really surprised that these runs went differently than I had expected. As is often the case, I learned something new.
All in all, downtown Houston was an enjoyable place to stay, eat, work, and run, and much fun was had.
I've been lucky in my years as a computer science professor to get to know some great teachers. Some folks embody the idea of the teacher-scholar. They are able computer scientists -- in some cases, much more than that -- but they have devoted their careers to computer science education. They care deeply about students and how they learn. My good fortune to have met many of these folks and learned from them is dwarfed by the greater fortune to have become acquaintances and, in some cases, their friends.
One of my favorite computer science educators, Rich Pattis, is receiving the SIGCSE Award Winner for Outstanding Contributions for CS Education at the 2006 conference -- this morning, as I type. I can't think of many people who deserve this award as much as Rich. His seminal contribution to the CS education is Karel The Robot, a microworld for learning basic programming concepts, and the book Karel the Robot: A Gentle Introduction to The Art of Programming, which has been updated over the years and extended to C++ and Java. But Rich's contributions have continued steadily since then, and he has been in the vanguard of all the major developments in CS education since. Check him out in the ACM Digital Library.
Rich titled his acceptance talk "Can't Sing, Can't Act, Can Dance a Little (On Choosing the Right Dance Partners)", a reference to a famous remark about Fred Astaire and how Ginger Rogers "gave him class". The talk is a trace of Rich's computing history through the people who helped him become the teacher he is, from high school until today. Rich found photos of most of these folks, famous and obscure, and told a series of anecdotes to illustrate his journey.
Those who know Rich wouldn't be surprised that he began his talk with a list of books that have influenced him. Rich reads voraciously on all topics that even tangentially relate to computing and technology in the world, and he loves to share the book ideas with other folks.
Rich said, "I get all of my best ideas these days from Owen Astrachan", and one particular idea is Owen's practice of giving book awards to students in his courses. Owen doesn't select winners based on grades but on who has contributed the most to the class. Rich decided to reinstate this idea here at SIGCSE by arranging for all conference attendees to receive his all-time favorite book, Programmers at Work by Susan Lammers. I've not read this book but have long wanted to read it, but it's been out of print. (Thanks, Rich, and Susan, and Jane Prey and Microsoft, for the giveaway!)
He also recommended Out of their Minds, by Dennis Shasha, which has long been on my to-read list. It just received a promotion.
Throughout the talk, Rich came back to Karel repeatedly, just as his career has crossed paths with it many time. Rich wrote Karel instead of writing his dissertation, under John Hennessy, now president of Stanford. Karel was third book published in TeX. (We all know the first.) Karel has been used a lot at Stanford over the years, and Rich demoed a couple of projects written by students that had won course programming contests there, including a "17 Queens" puzzle and a robot that launched fireworks. Finally, Rich showed a photo of a t-shirt given him by Eric Roberts, which had a cartoon picture with the caption "Two wrongs don't make a right, but three lefts do." If you know Karel, you'll get the joke.
The anecdotes flew fast in the talk, so I wasn't able to record them all. A few stuck with me.
Rich told about one of the lessons he remembers from high school. He went to class to take a test, but his mechanical pencil broke early in the period. He asked Mr. Lill, his teacher, if he could borrow a pencil. Mr. Lill said 'no'. May I borrow a pencil from another student? Again, 'no'. "Mr. Pattis, you need to come to class prepared." This reminded me of Dr. Brown, my assembly language and software engineering prof in college, who did not accept late work. Period. The computer lab lost power, so you couldn't run your card deck? The university's only mainframe printer broke? "Not my problem," he'd say. The world goes on, and you need to work with the assumption that computers will occasionally fail you. I never hated Dr. Brown, even for a short while, as Rich said he did Mr. Lill for a while. But I fully understood Rich when he finished this anecdote with the adage, "Learning not accompanied by pain will be forgotten."
Not surprisingly, some of the Rich's best anecdotes related to students. He likes to ask an exam question on the fact that there are many different infinities. (An infinite number?) Once, he asked students, "Why are their more mathematical functions than computer programs?" One student answered, "Because mathematicians work harder than computer scientists." (Get to work, folks...)
My favorite of Rich's student anecdotes was a comment a student wrote on a course evaluation form. The comment was labeled A Relevant Allegory:
In order to teach someone to boil water, he would first spend a day giving the history of pots, including size, shape, and what metals work best. The next day he'd lecture on the chemical properties of water. On day three, he'd talk about boiled water through the ages. That night, he'd tell people to go home and use boiled water to make spaghetti carbonera. But never once would he tell you to put the water in the pot and heat it.
That's what his programming classes are like -- completely irrelevant to the task at hand."
Rather than summarize Rich's comments, I'll quote him, too, from a course syllabus in which he quoted the student:
I like this comment because it is witty, well-written, and true -- although maybe not in the extreme that the author states. Teaching students to boil water is great for a high school class, but in college we are trying to achieve something deeper...
I acknowledge that learning from first principles is tougher than memorization, and that sometimes students feel that the material covered is not "applied".
Eventually, Rich's dance-partner history reached the "SIGSCE years". He showed two slides of pictures. The first showed a first generation of folks from SIGCSE who have become a long-term cadre that shares ideas about computer science, teaching, books, and life. The second showed later influences on Rich from among the usuals at SIGCSE. I was a bit surprised and highly honored to see my own picture up on Slide 1! I recall first meeting Rich at SIGCSE back in 1994 or so, when we began a long dialogue on teaching OOP and C++ in CS1. I was pretty honored even then that he engaged me in this serious conversation, and impressed by the breadth of the ideas he had collected and cultivated.
Rich ended his talk with a tribute to one of his favorite films, The Paper Chase. Long-time readers of Knowing and Doing may recall that I wrote a blog entry that played off my own love for this movie (and Dr. Brown!). Rich said that this movie has "more truths per scene" about teaching than any other movie he knows. As much as he loves "The Paper Chase", Rich admitted to feeling like a split personality, torn between the top-down intellectual tour déforce of Professor Kingsfield and the romantic, passionate, bottom-up, "beat" style of Dead Poets Society's John Keating.
Kingsfield and Keating occupy opposite ends of the teaching spectrum, yet both inspire a tremendous commitment to learning in their students. Like many of us who teach, Rich resonates with both of these personalities. Also like many of us, he knows that it's hard to be both. He likes to watch "Dead Poets Society" each year as a way to remind him of how his students must feel as they move on to the wide open wonder of the university. Yes, we know that "Dead Poets Society" is about high school. But, hey, "The Paper Chase" is about law school. You should watch both, if you haven't already.
Rich closed with a video clip from "The Paper Chase", a famous scene in which Professor Kingsfield introduces his class to the Socratic method. (The clip is 10.4 Mb, and even still not of the highest quality.)
This was an inspirational close to an inspirational talk, from a CS educator's CS educator, a guy who has been asking questions and trying to get better as a teacher for over twenty years -- learning from his dance partners and sharing what he has created. A great way to start a SIGCSE.
(UPDATE March 4: I have posted a link to the video clip from "The Paper Chase" that Rich showed. He has said that he will post his presentation slides to the web; I'll watch for them, too.)
SIGCSE begins tomorrow, but I arrived early for a pre-conference workshop. Back when I was appointed department head, my dean offered to send me to a workshop for new department chairs. I looked at the three-day schedule, the timing of it, and the cost, and decided that I could use the college's money and my time better in other ways. But then I learned about a workshop for heads at SIGCSE, which I was planning to attend anyway. This workshop lasted only one day and was organized by CS professors, which sounded better to me than three days talking about administration with folks in departments from all over campus. The dean was game to cover part of my expenses, so it worked out for everyone.
The day started with a cautionary tone. Time spent as a department head carries professional risk. Department heads don't do as much research as a regular faculty member, and they don't develop as many courses. The result is that they create little or no "portable wealth" in the academic marketplace. The result can be limited mobility and reduced opportunity for professional development at the home university.
It's worse yet. Department heads have precious few rights, less power than some people think, and lots of tasks that pull them away from research and teaching, which are the reasons most of us became CS academics.
Why would anyone take the job?
Like many of my colleagues at the workshop, I became head as part of a larger set of circumstances than just that I wanted to be head. But after a semester and a half, I know that my reasons for thinking that the job was worth my doing for a few years were right on mark. So I was not discouraged by the gallows humor with which we opened the day.
I won't give you a long, blow-by-blow summary of the day. We talked about all of the big issues that heads seem to face, wherever and whenever they are head: dealing with faculty, dealing with students, finding and allocating resources, managing lab facilities, monitoring legal issues, and "the leadership thing". We wrote down all of the items that would be part of an honest job description (something many of us don't explicitly have!), and it filled many pages of flipchart paper.
Here are some of the nuggets that will stay with me, and some of the things that I want to work on soon as a result of the discussion today:
That last hint gives rise to a new item on my will-do-soon list. I plan to conduct a survey of teaching assignments across the departments of my college to see what the real load on other professors really is. I suspect that many math professors engaged in research don't really teach six sections a year, and that many biology and chemistry professors have loads laden with lab courses that do not equate to a CS professor teaching a regular course -- one that likely needs to be updated regularly in order to be of real use to our students. This is something we've talked about in our department for many years, but now that I am head I do not have to settle for talk. Besides, the CS faculty deserve an equitable work load, and it's my job to ensure that they get one.
One thing I learned today is that, compared to many heads, I have a pretty good life. The other heads in my college have always been helpful to me in learning my job and offering advice. My dean is a good person, supportive of our department, and he helps me when he can. My colleagues in CS are, despite everything else, good people who want to do a good job. And they all seem genuinely interested in me doing a job, and they help me when they can. It's worth getting out in the world every once in a while if only to be reminded how good my life really is.
One day was perfect for this kind of workshop. It was long enough to make my mind race with ideas and possibilities, to give me a little burst of energy, but not so long as to become boring or indulgent.
Next up: SIGCSE proper, with some sessions on the future of computing and others on CS topics of particular interest, like compilers. Oh, and a reception at Minute Maid Park. Too bad the Astros are still at spring training!