December 27, 2006 10:58 AM

Holiday Filmfest

It's not a holiday tradition for me to watch movies, but this holiday weekend I had a chance to see several -- not counting seasonal fare such as The Santa Clause. Only one was new, but as my brother is fond of saying, "Hey, they were new to me."

Last night I finally got to see Proof, the only of the movies with a professional connection. I'm not a mathematician, but I can relate to the manic periods of productivity interleaved with periods of little or no progress. As Robert, the mad genius played by Anthony Hopkins, and his daughter Catherine, played surprisingly well by Gwyneth Paltrow, both say at different points in the movie, the key to those down times is to keep plugging way, trying something new, attacking the problem from different angles, chipping away at the problem even the effort seems fruitless. You want to be there, ready, when the next burst of progress arrives.

The movie also brought to mind G. H. Hardy's wonderful A Mathematician's Apology, which I referenced briefly a year or so ago. There is a persistent mythology that mathematicians make their greatest contributions to the the world at an early age, after which their creative powers decline. I've generally heard 35 as this threshold age, but in Proof the mathematicians are much less generous -- Catherine at 27 could already be past her prime. While I do believe that scholars lose a certain kind of stamina they need for making great breakthroughs as they grow older, but I don't buy into this Conjecture of Inevitable Decline at a young age -- and certainly not 27! Certainly the history of computer science is replete with examples of the great ones making seminal contributions well past 35 -- Knuth and Simon come immediately to mind. We do ourselves and our community a disservice when we make excuses for lack of productivity and creativity as we age. That said, not ever having been a Great One, I can only try to imagine the feeling that Hardy describes, and that must have accentuated Robert's madness, as they fall away from their peak.

My weekend began with a trip to see the new release Eragon live in the theater with my daughter. She took me to this movie as a Christmas present, and it made for a very nice dad-and-daughter outing indeed. Growing up, I was more into science fiction than fantasy -- Asimov, Clarke, Heinlein -- but my daughter has gravitated to fantasy. She has already read the book on which this movie is based, and its sequel, so she could fill me in whenever I had a question. If I were a literary critic, I would call Eragon almost wholly derivative of prior works, but then most fantasy is. As a moviegoer, I call Eragon an entertaining show. And Sienna Guillory as Arya -- wow.

Sandwiched between the previous two was a Christmas evening viewing of Dear Frankie, a gem of a movie that I'd never heard of before my daughters pulled it off the video store shelf. Jack McElhone delivers an affecting performance as Frankie, a deaf 9-1/2 year old who longs to see his father. Frankie believes his father to be at sea after leaving their family when Frankie was but an infant. In truth, Frankie's mom, Lizzie, played by the enchanting Emily Mortimer has been on the run from the father all those years, her son and mother frequently about Scotland. Lizzie has been responding to Frankie's letters to his dad for years, unwilling to tell him the truth. Rather than tell you the whole story, or give away too much, let me give you a better piece of advice: watch this movie, and soon. It's one of the best I've seen in years.

That's my turning playing Gene Siskel for a while.


Posted by Eugene Wallingford | Permalink | Categories: General

December 22, 2006 5:10 PM

I'm Not Being Funny Here

If you surveyed my students, I doubt that "funny guy" is one of the first phrases they would use to describe me. It's not that that I am humorless in the classroom; it's just that comedian isn't a natural part of my public persona. (At home, though, I am probably sillier than the average professor.) But I do try to take advantage of opportunities to have fun in class, whether with the material itself or with the many circumstances that arise whenever people -- and technology -- come together. I think that this sort of humor can be used to good effect in the classroom by any instructor. Of course, as with any skill, it takes some practice before most become very good at it.

Whether we are natural comedians or not, I think we can all learn something from comedians. I was recently reading an article by a guy who had taken a class on how to be a stand-up comic. The way these guys learned the craft was largely by trial-and-error: They wrote a short act and then presented it in front of their teacher and classmates. The criticism could be brutal, but the feedback helped them learn lessons about writing and delivery. We learn to programming in much the same way, but we can take one of our best critics wherever we go: the compiler. I think we could help our students learn a lot more about programming and software design by adopting the stand-up approach more often: having students present their code to instructors and fellow students, to receive feedback from real people. This is a natural part of a studio approach to instruction, which can be adapted to classes of different sizes in a variety of ways. Jim Waldo of Sun talked about the role of one-one mentorship of this sort in his Essays presentation at OOPSLA 2006.

But that article also suggested another way that we could learn from comics. The author asked Eddie Brill, who warms up David Letterman's Late Show audiences, what all the great comedians had in common. He answered, "They're honest, they're vulnerable, and they're not looking for approval." I think that two of these characteristics are no-brainers as essential to good teaching.

An instructor must be honest. Students sense insincerity better than many people realize, and they do not like being misled in the course of their learning. This might seem difficult, considering that most CS instruction requires simplification in order to teach most concepts. If I feel I have to explain all of the subtleties of public, protected, and private when teaching Java to CS 1 students, I will lose them before they can really appreciate how much fun programming is. But I don't think being honest means dumping details on students unfiltered or unstructured by our expertise; it means not teaching them facts as dogma that must necessarily be undercut later. I try not to overstate the reach of the rules I teach my students, and wherever possible I let them know that they are learning a simplification that we will enrich later. College students -- and I think younger kids, too -- are savvy enough to understand these distinctions, and they appreciate being involved in the unfolding of knowledge.

An instructor should never enter a classroom seeking approval. My students are not in my class to validate me, or to make me feel better about myself, or to boost my confidence. They're there to learn, to become part of a scholarly community. If I enter the room seeking approval, it will distort everything I do, from the material I choose to teach, to how I teach it, to how I evaluate their progress. The class isn't about me, it's about them -- or perhaps more accurately, about us and a set of ideas and skills, as we help them grow in what they know and can do. A comic who reaches out for the laugh will almost always be left wanting. Instructors reach out for the applause will either be left wanting by a disappointed class or will leave the room with a hollow and fleeting victory, having cheated the students.

That brings me to the third characteristic: vulnerability. Doesn't this contradict the previous advice not to seek approval? Even if it doesn't, should an instructor really be vulnerable? I don't think that being vulnerable is a contradiction at all, which is why the best comics can have both characteristics. Vulnerability is about being invested in the process, about caring what happens, about being open rather than closed. Even when considered this way, I know that some of my colleagues would disagree with the assertion that a CS instructor ought to be vulnerable. "That's one way to teach, I suppose," they would say, with almost but not quite a sneer in their voices. "But my style is built on authority, not vulnerability." I think I'm willing to concede that one can teach effectively without being vulnerable in a touchy-feely sense, but I'm not willing to concede that the best instructors are ultimately vulnerable in the sense that they are invested in their students' learning, that they care deeply about what their students come to know. Among the gruffest doubters of my assertion, the ones who are good teachers have this trait. And I know that I certainly do, or I would never feel like this -- or like this.

Now I know that I can watch Seinfeld and All in the Family with a clean conscience -- they can help me get better in the classroom.


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

December 21, 2006 2:49 PM

User Documentation and Instructional Design

Yesterday while clearing out some of the paper that has built up in my office over the course of the semester, I was reading through the conference copy of several sets of OOPSLA tutorial notes. One that grabbed by interest was from a tutorial that we had to cancel for lack of registration, on how to write user guides and tutorial documents. OOPSLA caters to software developers, and we knew at the time we accepted this one that the audience might be slim. But as I thought about the notes I was sad that we didn't attract more of an audience for this tutorial. It would have been useful to a lot of folks.

I was struck by the fact that writers of documentation for users face many of the same issues that teachers face. The first part of the tutorial dealt with users and learning: what they need to learn, and how they can learn it. The writer needs to remember that the user doesn't see the system in the same way as the developer, and may in fact be a different sort of person entirely. This echoes the recent "our students aren't like us" theme in several of my posts. The tutorial then proceeds to give concrete advice on the such topics as:

  • the differences between learning by reading and learning by doing
  • the cognitive burden shouldered by learners
  • the distinction between dedicates learners and midtask learners

I think that I sometimes assume that my students will be dedicated learners, focused on the ideas that I am trying to convey, rather than midtask learners, focused on getting something done. But I suspect that many students do a lot of their learning just-in-time, while attempting a programming assignment or homework problem. Midtask learners approach the learning task differently than the dedicated learner. In particular, they tend to look for what they need right now and stop reading as soon as they find it -- or realize that they won't! This makes brevity and specificity important elements of user documentation. They are just as important when writing instructions and tutorials for students.

The tutorial goes on to give concrete advice and examples on how to write instructions, how to induce rehearsal in the learner, and how to organize presentation to avoid overloading the learner. Almost every page of the notes has something to use as I think about refining my spring Programming Languages and Paradigms course. I've written extensive lecture notes for this course, of which I'm proud. But I think I'll use some of my prep time in the coming term to apply the ideas from this tutorial to my lectures. I can think of a couple ways to improve them:

  • varying the strategies I use to invoke rehearsal (zooming and out, changing modes of presentation, and supporting a new assertion with what we just learned)
  • making sure that my instructions clearly communicate their intention, endpoint, time frame, and possible signs o success and failure.

I guess I am not surprised by the similarities among writing user doc and writing for students (and teaching from that writing), but it never occurred to me to mine the former to help me improve the latter.

These tutorial notes were fun to read even without having the presenter in the room. They were written well, spare but engaging. That said, as with most printouts from slide presentations, I would have learned a lot more by having the writer tell the stories that were abstracted into her slides. And I definitely would like to see the examples that she had planned to distribute to illustrate the ideas in the tutorial.

User documentation is certainly not the only other writing form from which instructors can draw ideas and inspiration. Nat Pryce recently wrote about the idea of using the comic book as a form for end-user documentation, and there may be something we instructors could learn from comic book writers. Before you scoff, recall that the U.S. 9/11 Commission Report The Path to 9/11 was adapted into a highly-acclaimed comic book. (If I recall correctly, either artist Ernie Colon or writer Sid Jacobson is from my adopted state of Iowa.)

I think the OOPSLA crowd missed a good opportunity to learn from this tutorial. But there is one consolation... I believe that the tutorial presenter is currently writing a book on this topic. I'll definitely pick up a copy, and not because I plan to write a lot of user documentation.


Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

December 20, 2006 5:16 PM

The Long Tail as Software Designer

Almost every day I am reminded of how the way the world works is changing all around us. For example, Philip Windley writes of the day, coming soon, when MP3 player are like pens -- "everywhere, given away, easily abandoned, even disposable". (I almost wrote "ballpoint pens", but that would betray my ever more apparent state of being a dinosaur.)

Then I learned about My Dream App, which lies at the convergence of American Idol, the web, and the independent software world:

My Dream App is a grand experiment to see what happens when you combine the expertise of some of the best talents in the software and tech world with great ideas and feedback from everyone else.

Like Idol, My Dream App had open tryouts to get into the pool of contestants and then judging by a panel of experts as the apps were winnowed through a series of rounds. However, My Dream App's panel of experts puts Idol's to shame! At the end, the viewing public selected winners by voting on-line. At stake was not a recording contract but a contract to have the idea implemented by a crack team of Mac developers, with royalties for life. The coding team has some great developers, including one of the guys behind SubEthaEdit.

Simon (Cowell) says: thumbs down!

Steve Wozniak

While I'm not all that enamored by most of the apps that finished at the top of the pile, with perhaps one exception, I think that this is a great idea. It exploits the power of a large number of people to brainstorm ideas and then allows them to participate in a selection process that is guided by informed folks who can provide a more focused perspective. And the allure of having Woz act as Simon Cowell must surely have attracted a few people to take their shot at submitting an idea. "That's the most pathetic feature I've seen since Bill Atkinson wanted to prevent users from specifying their own desktop patterns on the original Mac."

This is a new variation in the space of idea generation that I have written about before. On one end of a continuum is the great solo creator like Steve Jobs, who seems to have an innate sense of what of is good; at the other end is Howard Moskowitz, who produces an insanely large set of possibilities, including strange ones that we think no one might like, and then lets people discover what they like. My Dream App is more in the Moskowitz vein, but with a twist -- let everyone with an internet connection build your set of possibilities for you, and then let the crowd work with informed guides to winnow the set. The ubiquity of the web makes possible a collaborative process that would have been unwieldy at best in earlier times.

I wonder long it will be before a mainstream producer -- say, an automobile manufacturer -- uses this sort of approach to design a mainstream product. Just imagine... the 2009 Long Tail coupe, original idea by a insurance executive in Hawarden, Iowa, refined by the masses under the watchful eye of Lee Iacocca. Many auto manufacturers do worse on their own. When harnessed in the right sort of process, the wisdom of the crowd is a powerful force.


Posted by Eugene Wallingford | Permalink | Categories: General, Software Development

December 18, 2006 4:00 PM

Another Way Our Students Are Different From Us

On my CS 1 final exam, I asked the students to suggest a way that we could hide a string in a sound, where a Sound object is encoded as an array of sound samples in the range [-32768..32767]. Here is the last part of the question:

Under your scheme, how many characters could you hide in a song that is 3:05 long?

My caricature of the typical answer is...

It depends.

Actually, most of the students were a bit more specific:

It depends on the sampling rate.

Of course it does. I was looking for an answer of this sort:

(185 * sampling rate) / 100

... for a scheme that stored one character every 100 sound samples. It never occurred to me that most students would get as far as "It depends on the sampling rate." and just stop. When they realized that they couldn't write down as answer such as "42", they must have figured they were done thinking about the problem. I've been doing computer science so long, and enjoying math for much longer, that I naturally wanted to write a formula to express the result. I guess I assumed the students would want to do the same! This is yet another example of how our students are different from us.

Fortunately, nearly all of them came up with a scheme for hiding a text that would work. Some of their schemes would degrade the sound we hear considerably, but that wasn't the point of the question. My goal was to see whether they could think about our representations at that level. In this, they succeeded well enough.

Well, I guess that depends.


Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

December 16, 2006 2:25 PM

The Prospect of Writing a Textbook

Writing a book is an adventure. To begin with, it is
a toy and an amusement; then it becomes a mistress, and
then it becomes a master, and then a tyrant. The last
phase is that just as you are about to be reconciled to
your servitude, you kill the monster, and fling him out
to the public.

-- Winston Churchill

So maybe I think of myself as a writer, at least part of the time. Why haven't I written a book -- especially a textbook -- yet? My wife often asks when my book will be ready. She would like to see all the work I've done, both solo and with my many friends and colleagues, to be more visible in the world. My parents asks occasionally, too, as do some other colleagues. For many folks, a book is "the" way to make one's ideas usable by others. Papers, conference presentations, and a blog aren't enough.

To be fair my wife and many others who ask, I have been working for several years with colleagues on new ways to think about teaching first-year CS courses, motivated by real problems and pattern languages. We have progressed in spurts and sputters, as we learn more about what we are trying to do and as we try to make time to do the hard work of developing something new. I have learned a lot from this collaboration, but we haven't produced a book yet.

I suppose that I just haven't found the project that makes me write a book yet. A book project requires a huge amount of work, and I suppose that I need to really want to write a book to take on the yoke.

Other than my doctoral dissertation ("Conceptual Retrieval from Case Memory Based on Problem-Solving Roles") and several long-ish papers such as a master's thesis ("Temporal Logic and its Use in the Symbolic Verification of Hardware" -- written in nroff, no less!), I have never written a large work. But I occasionally sense what it must be like to write a textbook, a monograph, or even a novel. When I am at my most productive producing ideas and words, I see common triggers and common threads that tie ideas together across time and topic. When I am blogging, these connections manifest themselves as links to past entries and to other work I've done. (Due to the nature of blogging, these links are always backwards, even though my notes often remind me to foreshadow something I intend to write about later and then to link back to the current piece.) However, I know that when I have blogged on a topic I've only done the easy part. Even when I take the time to turn a stream-of-consciousness idea into a reasonably thoughtful piece for my blog, the hard work would come next: honing the words, creating a larger, coherent whole, making something that communicates a larger set of ideas to a reader who wants more than to drop occasionally into a blog to hear about a new idea. I don't think I fear this work, though I do have a healthy respect for it; I just haven't found the One Thing that makes me think the payoff would be worth the hard work.

The closest thing to a textbook that I have written are the lecture notes for my Programming Languages course. They are relatively complete and have been class-tested over several years. But these are largely a derivative work, drawing heavily on the text Essentials of Programming Languages and less heavily on a dozen other sources and inspiration. Over time, they have evolved away from dependence on those sources, but I still feel that my notes are more repackaging than original work. Furthermore, while I like these notes very much, I don't think there is a commercial market that justifies turning them into a real textbook, with end-of-the-chapter summaries and exercises and all that. They serve there purpose quite well -- at least well enough -- and that's enough for me.

What about the personal and university identity to be gained by writing a text? Reader Mike Holmes pointed me to a passage on the admissions web site of one of our sister institutions that their "professors actually write the textbooks they and professors at other colleges use". That's a strong marketing point for a school. My university likes to distinguish itself from many larger universities by the fact that our tenured faculty are the ones teaching the classes your students will take; how much better if those professors had written the text! Well, as Mike points out, many of us have had courses with author-professors who were average or worse in the classroom. And if a textbook has few or no external adoptions -- as so, so many CS texts do -- then the students at Author's U. would probably have been better off had the author devoted her textbook-polishing efforts to improving the course.

Maybe this is all just a rationalization of my lack of ambition or creative depth. But I don't think so. I think I'll know when a book I'm meant to write comes along.

Could my work on this blog eventually lead to a book? Another reader once suggested as much. Perhaps. It is certainly good to have an outlet for my ideas, a place where they go from abstractions to prose that might be valuable to someone. The blog is also an encouragement to write regularly, which should help me become a better writer if nothing else. Then, if a book I'm meant to write comes along, I should be prepared to write it.


Posted by Eugene Wallingford | Permalink | Categories: General, Teaching and Learning

December 12, 2006 6:00 PM

Am I a Writer, Too?

[Written on a plane between Detroit and Minneapolis yesterday, returning from an OOPSLA 2007 planning meeting in Montreal.]

I have at various times in the life of this blog proclaimed myself a runner and a programmer. (The latter post has drawn comments from several readers, including an out-of-context "Me, too" from Joe Bergin in a Montreal restaurant Friday night!) My many posts on teaching my courses leave little doubt that I also think of myself as a teacher.

My flight home today leads me to to want to say "I am a writer", too. Over the last year or more, I have gone through occasional droughts posting here, and even when I have written I have not always felt particularly inspired. But stimulate me -- send me to a conference, or to a meeting with interesting people; give me a good book; turn me loose in a new course to teach -- and the flood gates open.

A few moments ago, the flight attendant told us to turn off all portable electronic devices, including laptop computers. So here I sit, scribbling this message on two small Northwest Airlines napkins received as part of the beverage service earlier. Two napkins, filling both sides and now writing up the margin. The words won't stop.

Flying home led me to think about what I had learned about my job as communications chair, and suddenly all sorts of ideas for new articles began to flow, and ideas for how to grow, merge, and finish up ideas that have been sitting inchoate in my "blogs to write" folder for days and weeks. Some of the ideas were triggered by reading I'd done on the plane; others, from conversations over the weekend; yet others, from who knows where.

Let's just say that my hopper is hopping and should serve well in the coming days as I take time to blog.

Can I be a runner, a programmer, a teacher, and a writer -- and a husband and a father -- all at once? Yes. I certainly admire many of my colleagues and friends who seem to be so many things, so well. Perhaps such breadth is just a part of being human. We are certainly lucky to live in a time and place where we can be so many people at once.


Posted by Eugene Wallingford | Permalink | Categories: General

December 11, 2006 7:29 PM

Learning about My Communications Job ...

... on a last December morning in Montreal, where I am on the job.

I awoke for an early morning run to snow, the wet fluffy snow of temperatures near 0° C. In the downtown area, all that remained were wet streets, but as I jogged toward Mont Royal the snow was still falling and the 6-8% grade up Rue Peel was covered in an inch or so. I love to run in falling snow, and my first snow run of the year is often special. I enjoyed this one as much as usual.

Just past half way on my out-and-back route, I missed a turn that seemed obvious yesterday. Perhaps it was the snow-covered street signs, or my snow-covered glasses. The result was 17 minutes or so of backtracking and retracing my steps, and a planned 8-miler turned into a 10-miler that lasted into Monday morning rush hour traffic. The 6-8% grade down a snowy Rue Peel was, oh, let's say more challenging than the run up. I survived with no spills but a few minutes of my heart pounding a bit more than usual.

I hope that the OOPSLA 2007 wiki, which we hope to have up and running any day, will be a place for OOPSLA-bound runners to share advice on routes and warnings of things to watch for. We usually launch the conference wiki at or just a few weeks before the conference, but I think having it running all year long will offer a chance for potential conference attendees and other altruistic souls to build community around issues related both to the conference and to our personal pursuits in Montreal. This is a part our vision for the communications component of our conference organization.

As I checked out later in the morning, I received a more expensive surprise. It turns out that the complimentary shuttle from the Hyatt to the Montreal central bus station, which I thought ran on a regular and frequent schedule, requires a one-hour advance registration. There was no information about this in the packet I received from our logistics company, nor at the L'Aerobus station, nor in the hotel itself. This inconvenience followed the general sense of disorientation and complexity I felt on the night I arrived and strengthened my desire to incorporate a useful Local Travel on the conference web site. Anything we can do to ensure that all of the ancillary things associated with conference travel go well, the more likely we can create an awesome OOPSLA 2007 experience for attendees. Yet more conference communications! Yet another element to my position on the conference committee.

Before I began to dig into this position during OOPSLA 2006, I assumed that most of my activities would focus on the conference content: calls for submissions, the advance program, the program on the web site, the final program, and the much-missed Program-at-a-Glance that makes the days of the conference easy to follow and plan. But I have come to understand that communications is much more than simply organizing the program for presentation in paper and bits. In fact, I'd say that that task is merely one example of a larger purpose. It is really about eliminating the friction that naturally comes at all stages of participating in OOPSLA. It is about serving the informational needs of submitters and attendees.

I have come to admire the underlying sense of duty that runs throughout our conference committee. General chair Dick Gabriel has his pulse on both ends of the spectrum of tasks that faces the committee: those little details that seem to matter only when something goes wrong, such as web-site navigation and hotel reservations, and the big picture of moving the conference forward for which he is so well-known among the OOPSLA committee, such as Onward! and the Essays track. He certainly recognizes the financial implications of falling down on the little services, which affects both the current year's attendance and the possibly future years' attendance, but I don't think that this is what motivates him. In any case, just now I am short on the kind of big ideas that can move the conference in a new direction, I am hoping that my attention to the details of our communicating well to OOPSLA participants can help the rest of the committee put on a winning conference.

And I am not saying all these nice things just because Dick graciously picked up part of a dinner tab that the conference budget could not last night at Montreal's Globe restaurant, attended by the committee members who had stayed an extra night in order to do more committee business and scout the area. The Globe offered a fine menu extravagant in seafood and a mix of French and North American cuisine, at prices that left this small-town Midwestern boy in a state of awe. The waitstaff was remarkably attractive and, um, shall we say, enticingly well-dressed. While I probably won't dine at this establishment on my future trips to Montreal, I can cherish the memory of this visit's delights.

Finally, during dinner conversation, I learned of the next big thing that will rock the software world, which will explode out of OOPSLA 2007 as so many revolutionary ideas have sprung from past OOPSLAs: ribosome-oriented computing. Keep your eyes glued to Google; this has the potential to make an international superstar out of postmodern software prophet Robert Biddle.


Posted by Eugene Wallingford | Permalink | Categories: General, Running

December 10, 2006 1:48 PM

Needs, Courage, and Respect

Two comments from the human side of our world have caught my eye in the last little bit:

On needs, courage, and respect

Dale Emery relates these concepts concisely:

A big part of courage is remembering that my needs matter. A big part of respect is remembering that the other person's needs matter.

In many ways, it's easier for me to integrate the latter into my daily life than the former. I usually feel guilty for placing my needs too high in the pecking order. Perhaps I place too much concern on the risk of being self-centered. (And that probably because I already have that weakness!)

On badmouthing one's competitor

A lot of folks have linked to Tom Peters' article on "loving thine enemy", but my take on Peters' article best matches Jason Yip's take:

My take on this is that I don't want to be someone who badmouths other people for my own self-interest. And that's enough.

Well said. I'm certainly sympathetic to the pragmatists' philosophical stance, which would summarize Peters' position as saying that working to hurt your competitors "doesn't work". But one ought not need an economic or altruistic reason not to speak ill of others. It is simply wrong.


Posted by Eugene Wallingford | Permalink | Categories: General, Managing and Leading

December 09, 2006 1:08 PM

Hello from Montreal

OOPSLA 2007 logo - embrace the beaver!

Bienvenue de Montréal! My previous post was written on the plane to Quebec for the December OOPSLA'07 planning meeting. This year, I am communications chair for the conference, which means that I have a diverse set of responsibilities defined around "getting the word out". (Don't worry; I won't turn this blog into a conference shill.) This includes the design of the advance and final programs, as well as helping to shape the content and organization of the web site. I'm part of a team consisting of a graphic artist and a person focused on advertising, which is good, given my lack of skills in the former and lack of feel for the latter.

My big challenge this year is to find a way to communicate the rich diversity of our program -- and it is richer and more diverse than any computing conference I know of -- to the people who should be at OOPSLA next year. We have all been talking about this for a couple of years, but now it's my job. How do I help attendees, especially newcomers, navigate their way through the conference? Someone this morning likened OOPSLA to Paris, a wild circus of ideas and events that can educate and enthuse and enlighten and entertain most anyone who cares about programs and the art of programming. It's a provoking analogy that I'll have to explore. For example, how do we help potential attendees find us as a "vacation spot" and plan their trip?

As when I attended SugarLoafPLoP, I find the change in local language to be surprisingly disorienting -- even in a place where almost everyone speaks English as well as I. This exposes my parochial upbringing and my rather limited travel experiences as a professional. It probably also says a lot about a self-insularity that I need to break out of. EuroPLoP and ECOOP are calling me!

Given that I'll spend a total of a couple of weeks over the next year among the Quebecois, I think that I should try to learn a little French beyond "oui", "merci", and "non parlez-vous Francais". When I went to Brazil, I set the too-ambitious goal of learning some conversational Portugese. This time, I will set the less imposing and more achievable goal of learning some vocabulary and a few key phrases. (My colleague Steve Metsker says that he sets the goal of learning 50 words in the local tongue whenever he travels to a new land.) At least I can learn enough to show Montreal residents that I respect their bilingual culture.

the view of Montreal from Mont Royal

I am not running ready to write a new installment of "Running on the Road" yet, but I am looking forward to starting my research. After a long few weeks at the office, three hard days in a row on the track, and a long day of travel, this morning found me resting peacefully. The great news about our location in downtown Montreal is proximity to the running trails along the Fleuve Saint-Laurent and in the wonderful Parc du Mont-Royal. I plan to run tomorrow's 12-miler on the trails of Mont Royal -- not climbing the mountain, but on a trail that circles near the base. Then Monday I'll try the trail along the St. Lawrence. My May visit will give me more opportunities to explore the possibilities.


Posted by Eugene Wallingford | Permalink | Categories: General, Running

December 09, 2006 7:12 AM

An Unplanned Risk

Those of you who are professors or students will appreciate this.

In what was either the stupidest move of my teaching career or a sign of ultimate boldness and confidence, on Tuesday I returned an exam to my students and then closed the session with student evaluations. This wasn't just any exam. The class average score was just under 43%, and only one student scored high enough to pass given the standard grading scale I use -- and that was a C. As I told them then, I doubt they will encounter many other professors who would return such an exam and do student evals the same day.

For those of you who've never had me for a class, let me explain that I do not typically curve individual exams or other assignments. I've always felt that curving exams was a bad idea. I prefer to take a look at the grades as they stand at the end of the semester and make any adjustments to the grading scale then that might be necessary so that final grades reflect the work of the class and individual students. (There is probably another good blog topic for another time.)

Student evaluations play an important role in the academic world. For good or bad, they are one of the few practical, low-cost ways that we have of assessing the quality of teaching. As an instructor, I often enjoy getting feedback on particular elements of my course, especially the new things I have tried, to see how students perceive them and how I might implement them better. Unfortunately, the standard "instrument" that most schools use for student evaluations doesn't give very good "formative feedback" of this sort. Worse, it asks students a lot of questions that they really can't answer with any authority. As a result, these evaluations are also of limited value providing evaluative feedback.

But that is neither here nor there. Student evaluations of one form or another are with us for now, I was planning to have my done last Tuesday. Then I graded the exam. As I recorded the scores, it occurred to me that returning them on evaluation day created an interesting situation. I suppose that I could have postponed one or other to the last day of classes, but putting of either was inconvenient. And to be honest, I really couldn't see myself waiting on either. I have always prided myself in not allowing the presence of outside observers to affect my classroom behavior. As an untenured faculty member, I had visitors from my department's professional assessment committee in classes on several occasions each fall. On principle I preferred that visitors come unannounced, lest I change my behavior in anticipation of their presence -- or that they think I might have. In this case, it just seemed wrong to toy with the process, even knowing that the evaluations could be slanted by transitory emotions.

Perhaps rather than being an act of boldness this was an act of trust -- trust in the students to judge the course and my teaching of it fairly, looking at the big picture rather than just the exam score or how they felt that day. Trusting them seemed only fair, as I had just asked them to trust that their final grades would reflect an honest evaluation of their work and learning over the course of the whole semester, and not the scarily low score on the exam I just handed them.

Results from the assessment won't be available for a few weeks. We'll see. As for the exam, I clearly missed the mark. The students thought it too long, but even after grading it I don't think that was the real. Had I given most students twice as much time, they would not have scored significantly better. They simply didn't understand the material well enough. This exam mostly covered computation with sound, with a little bit about text and files at the end. For some reason, the students were not prepared well enough for this exam. I do not have a good sense of why just yet. The easy answer for the instructor is always that they students didn't study hard enough, or take the material seriously. While that can be true, it's usually just a reflexive excuse that saves the instructor's own feelings. In what way did my in-class exercises, demonstrations, and explanations not do the job? More work to be done...


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

December 02, 2006 10:42 AM

Writing Code

Here's the thing. I like to write code.

I like to write code that most people take for granted. I like to write code to solve hard problems. I like to write simple programs. I like to solve the programming assignments that I set before my students. I like to discover problems to solve and then solve them with code. Sometimes, I like to make up problems just so I can write code to solve them.

A colleague of mine is fond of reminding university professors that they are not like most of our students. He means that in the sense that we professors were usually good students, or at least students who liked school, and that we can't expect our students to think the way we do or to like school the way we did. This can be useful as we design our courses and plan our day-to-day interactions with students. It's wise for me to remember that I am probably not like all of my students in another way: I just love to write code.

One of my great joys as an instructor is to come across a student, or even a class full of students, who love to write code. I enjoy working with them in class, and on independent projects, and on undergraduate research. I learn from them, and I hope they learn a little from me along the way:

Ultimately we learn best by placing our confidence
in men and women whose examples invite us
to love what they love.
-- Robert Wilken

One thing is certain. I love to write code.


Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning