In this era of rising costs, heightened competition, and falling public support for education, universities are becoming more and more driven by public relations. I encountered a perfect example at a meeting this morning.
One of the offices on campus was demoing a beta version of a new on-line tool that will help the university interact with students and community colleges. They plan to go 'live' with with the tool later this summer. Right now, they are introducing the tool to faculty on campus, both to get feedback to improve the program but also to build awareness of the tool among potential stakeholders.
Further, before going live, these folks plan to visit community colleges around the state to teach them about the tool, to build awareness among another key group of stakeholders. Then they'll present the tool to students here at the university and elsewhere.
One of their reasons for the concerted effort to spread the word so broadly was very pragmatic: After university public relations sends out press releases on this new tool, they expect the press to immediately ask community college folks what they think of about the tool's effect on them and their students. And the university wants these folks to be able to respond to press queries in an informed -- and, hopefully, positive -- way. Good words in the press make for good public relations.
The fact that the university is making an effort to educate potential users and stakeholders is not unusual; I'd expect the same for any new tool. What struck me was the deliberate effort to move the education stage so early in the process, as a part of the PR initiative. And the campaign of enlightenment won't be limited to people directly affected by the tool and its use; the university also plans to demo the tool to key legislators in the state and in the districts served by the community colleges. University/community college relations are a hot political issue these days, and the university wants fair attention given to its efforts to meet the desires of the folks who hold the purse strings, and the folks who elect those folks.
The PR campaign goes farther than just educating stakeholders. The unit responsible for this tool is already working on trademarking the name and logo of the software, to solidify their use in PR and to prevent unscrupulous competitors from swooping in after the launch and stealing intellectual property. (That flowery prose is mine, not the universities.)
I can't say that I blame the university for working so hard to shape its image before the legislature and the public at large. Perception is important. With so many entities competing for state appropriations, the university needs to sell itself better. Some might say that public agencies aren't competing, but they are. Within any given political culture, public funding is limited, so choices have to be made.
So long as the university doesn't subvert its purpose, or do things it wouldn't otherwise do for the sake of publicity, playing the PR game seems an unavoidable reality these days.
I've already about my department's effort to market a new program in bioinformatics. I view our efforts as a reasonable attempt to make information available to the people who need it in order to make informed choices about careers and educational opportunities. We will be moving forward this summer to let more students and teachers know about our program. For now, you can see a couple of pieces of literature developed by the university's PR department to help us, an 11"x17" poster (right) and an 8-1/2"x8-1/2" bifold brochure (PDF).
Last week, I ran 38 miles. In most respects, that is hardly remarkable. I ran 41 miles or more most weeks of 2005, and 38 miles was my usual week for most of 2004. But I hadn't had a normal running week since at least the middle of March, and I have to go back late February to find more than a week of normalcy. The culprits were manifold: trips to Houston, Carefree, and Portland; the long-lasting bugs that I brought home with me from each; and a pair of pesky hamstrings. Hence my happiness at having a merely ordinary week, one in which all I managed to do was to run my ordinary mileage every day in unremarkable times.
All winter, I seemed to be running a bit slower and more labored than I expected. In retrospect, this was probably a symptom of the overuse that eventual hammered my hamstrings. Last week's running may have been unremarkable in the grand scheme of things, but in context it offered one piece of hope: I ran 20 km (12.4 miles) for my long Sunday run in only 1:42. I wasn't trying to run faster than I've been running; the speed came naturally. I even managed a 7:56 mile near the end of the run. And the hamstrings felt fine.
I started this week with a 5-miler this morning, and it offered another sign that I am close to normal. Without any particular effort to go fast, I had my best time on the route in many months, probably since September.
Uncharacteristic patience has paid off for me over the last couple of months. I tend to rush back into my regular miles and speeds as soon as I think I can, but with so many different problem areas I found myself able to hold back, taking it easy some days and off on others. I may have taken it even easier when the hamstrings began to give me trouble; those muscles have definitely taught me to respect their power.
I sometimes feel guilty talking about the "struggle" to get back to a comfortable level after only eight or ten weeks of falling off pace. My wife has been trying to get back into a running routine after a few years away, and that has been much more of a challenge than what I have experienced. A friend recently told me that he had taken up a simple running program for the first time. These two are doing a good thing for their bodies (and minds), but there are days when starting from scratch must seem pretty daunting. The fact that these folks can stick with forming a new habit and training their bodies makes me realize that I'm in a pretty good place; my expectations are more of a problem than my body or habit.
Anyway, I am going to try for one more week of the very good usual, with no particular concern for speed or hills or intervals. Then I hope to spend a couple of weeks getting ready for our local half-marathon on June 25, not as a race with expectations of blowing away my PR but as a training run that shows I am ready for what comes next: training for the Twin Cities Marathon. For now, I will enjoy the usual, more than usual.
As a part of seeing my wife and daughters off to Italy, I cooked a few special meals for them on Sunday and Monday. One friend suggested that I needn't have bothered, because they will encounter much better food in Italy, but I think that an unusual meal prepared by Dad is still a nice treat -- and my wife loved not having to think about any meals for the last couple of days of packing and preparing. Besides, I'm not too shabby in the kitchen.
I like to cook. I'm not an accomplished chef, or anything of the sort, just an amateur who like to work in the kitchen and try new things.
While blanching asparagus for my last and finest effort of the weekend, I remembered an article that ran in our local paper last March under the headline Cookbooks simplify terms as kitchen skills dwindle. It discusses the dumbing down of cookbooks over the last couple of decades because Americans no longer know the common vocabulary of the kitchen. These days, recipes tend not to use words like "blanch", "dredge", or even "saute", "fold", and "braise", for fear that the casual reader won't have any idea what they mean. Cookbooks that buck the trend must provide detailed glossaries that explain what used to be standard techniques.
In some ways, this is merely a cultural change. People generally don't spend as much time cooking full meals or from scratch these days, and women in particular are less likely than their mothers to carry forward the previous generation's traditional culinary knowledge. That may not be a good or bad thing, just a difference borne out of technology and society. The article even implicates the digital computer, claiming that because kids grow up with computers these days they expect everything, even their cooking, to be fast. Who knew that our computers were partly responsible for the dumbing down of America's kitchen?
I sometimes think about connections between cooking and programming, and between recipes and programs. Most folks execute recipes, not create them, so we may not be able to learn much about how learning to programming from learning to cook. But the dumbing down of cooking vocabulary is a neat example for how programs work. When a recipe says to "fold" an ingredient into a mixture, it's similar to making a procedure call. Describing this process using different terms does not change the process, only the primitives used to describe the process. This focus on process, description, and abstraction is something that we computer scientists know and think a lot about.
In a more general teaching vein, I chuckled in my empathy for this cookbook editor:
"Thirty years ago, a recipe would say, 'Add two eggs,'" said Bonnie Slotnick, a longtime cookbook editor and owner of a rare-cookbook shop in New York's Greenwich Village. "In the '80s, that was changed to 'beat two eggs until lightly mixed.' By the '90s, you had to write, 'In a small bowl, using a fork, beat two eggs,'" she said. "We joke that the next step will be, 'Using your right hand, pick up a fork and...' "
Students probably feel that way about programming, but I sometimes feel that way about my students...
... which bring me back to my day job. I have reason to think about such issues as I prepare to teach CS 1 for the first time in a decade or so. Selecting a textbook is a particular challenge. How much will students read? What kinds of things will they read. How well can they read? That seems like an odd question to ask of college freshmen, but I do wonder about the technical reading ability of the average student who has questionable background in math and science but wants to "program computer games" or "work with computers". Colleagues complain about what they see as a dumbing down of textbooks, which grow in size, with more and more elaborate examples, while in many ways expecting less. Is this sort of text what students really need? In the end, what I think they really need are a good language reference and lots of good examples to follow, both in the practice of programming and in the programs themselves. It's our job to teach them how to read a language reference and programs.
My selection of a CS 1 textbook is complicated by the particular politics of the first year curriculum in my department. I need something that feels traditional enough not to alienate faculty who are skeptical of OO, but true enough to OO that Java doesn't feel like an unnecessary burden to students.
Postscript: Many recipes require that vegetables be blanched -- scalded in boiling water a short time -- before being added to a dish. Blanching stops the enzyme action, which allows them to stay crisp and retain their color and flavor. Here is a simple how-to for blanching. I didn't lear this from my mom or any of the cooks in my family (including my dad); I learned it the old-fashioned way: I ran into the term in a recipe, I wanted to know what it meant, so I looked it up in the cookbook. If we could give our programming students the right sort of reference for looking up the terms and ideas they encounter, we would be doing well. Of course, some students of programming will be like some students of cooking and try to fake it. I don't recommend faking the blanching of asparagus -- it's a temperamental vegetable!
As I mentioned yesterday, as father to two active daughters, I sometimes make price-conscious decisions in other areas. The expenses of fatherhood are on my mind right now, because I have a large credit card bill in store... On Monday of this week, my wife and daughters left for a two-week trip to Italy. They'll be staying with friends who are stationed at Aviano Air Base, in northern Italy not too far from Venice. The friends will serve as local hosts and tour guides, which makes such a big trip less daunting.
This will be a great experience for the girls. They will be missing the last two weeks of classes at school, but they'll learn far more on the trip than would during two weeks in school (especially, sadly, the last two weeks of school, when things seem to wind down a bit too fast for my tastes). As Andy Hunt wrote a while back, travel expands the brain. I am so glad that they have this opportunity, and a bit envious.
What about me and my opportunity? Bad timing. This is the end of the academic and fiscal years at school, and both present me with things that have to be done in the near-term. Besides, I didn't have the most productive spring and so owe my department some work that I'd promised earlier. On top of all that, I've been tired, run down, and injured since the end of February or so, and I just need time to recover. As much as I miss my wife and girls already, I am glad to have some quiet time to rest and relax my mind a bit.
We thought about delaying the trip until later in the summer and traveling as a family but, to tie back to my previous post yet again, the cost of airfare rose dramatically as we got into traditional summer travel dates. We also started to run into conflicts with other summer activities. In the end, we decided that the opportunity was too good for Mary and the girls to pass up... So now I look forward to frequent e-mail, an occasional phone call, and when they return a thorough review from the journals that they are all keeping. (No, we didn't set them up to blog their trip, though they'll be taking plenty of digital photos!)
It's too bad we couldn't make a later trip fit our schedules and budget; Italy would have been a great change of scenery for me, too. I've not yet been to Europe, and I know I'd love to see so much of it. The end of next month would have been perfect: I could have attended ITiCSE -- in Bologna, no less! Alas, the airline tickets would have been $1400 or more each, and the idea that the price of my ticket would have been tax-deductible just wasn't attractive enough.
It seems that folks have been discussing a flap between Google and Yahoo about choice in the search engine market. "Choice" has become a loaded term in several political contexts over the last couple of decades, and I suppose that this context is political in its own way.
I don't have much to say today about the Google, Yahoo, Microsoft situation, but something Jeremy Zawodny said recently struck a chord:
First off, I agree that companies should compete based on quality. But Microsoft and McDonald's are both shining examples of how that's not necessarily the way it works when "the market" is involved in the decision making. Price and convenience tend to trump quality.
Far be it from me to defend Microsoft and McDonald's, neither of whose products I use with any frequency. But... it seems Jeremy is saying that companies compete based only on quality, whereas the market introduces unfortunate forces such as price and convenience into the mix.
Why should companies compete based only on quality?
Quality is only one good. Other features have value, too. I don't think the market introduces issues such as price and convenience into the equation so much as expose what people really value.
I think that I value quality, but I also value other things in this world. In particular, I am often a price-sensitive consumer. With two daughters to raise, I sometimes have to make choices based on both quality and price, if I want to save money for other purchases I want to make.
In the search arena, if Yahoo! or some other company creates the absolute best, highest-quality search engine, but it costs a pretty penny, I may choose a "lower-quality" provider simply to conserve my scarce resources for something else that I value. And I may not suffer at all for my choice; good enough is often good enough.
We face this kind of choice in software development, of course, and folks like Richard Gabriel have written about the phenomenon's effect in the software world. Agile methodologies encourage us not to build the Perfect Solution if we aren't gonna need it. I suppose that the choice between "do the right thing" and "do the simplest thing" is still an open question in the software world, with many folks not enamored with the agile approach to things, but I think in the long run "do the simplest thing" will win out -- and produce both the most software and the best software.
This is all basic economics: we have to make choices in a world of scarce resources and conflicting values.
As something of a disclaimer, while I can pinch pennies with the best of them, I'm not a "least common denominator" kind of guy. I don't eat a lot of fast food, at McDonald's or elsewhere, because I value some things more than the convenience and immediate price savings over some of the alternatives. I'm writing this blog entry on a computer made by a company that has built its reputation on the idea that it makes better products. Users of these products seem prouder than most to be using the better tools. And those of us who use these products pay a small premium to do so. When I buy a new computer, I take quality and price into account, along with a whole host of other factors, including convenience and the intangibles of my experience using the product.
I value quality, but I value many other things, too.
(Oh, and if Jeremy didn't mean what I thought he meant, I apologize for dragging him into this. His blog entry was simply the trigger for this piece. For more on triggers in writing, start with this piece by Richard Gabriel. I also recommend the Hugo book that Richard cites.)
Several of my friends and colleagues have commented on the end of the academic year, which is different in some ways for me now that I am doing administrative duties as well as teaching. I've been known to do dance of joy at the end of a tough three-course teaching semester. Now my duties spread into the summer, but it's still nice to have a different rhythm to my days and weeks.
I am reminded of this little story by Chad Fowler, called Fight The Traffic:
I got in a cab last night heading from Washington D.C. to the Dulles airport. I was a block from the White House and traffic was stopped behind a crowd that was pushing its way in to see the President.
The old Ethiopian cab driver suddenly kicked the taxi into gear and zipped around a line of cars, edging us five cars closer to freedom.
"I hate traffic", he grumbled.
"You picked the wrong job, then, didn't you?"
"No! I love my job. My job is to fight the traffic."
In some ways, department heads are like cabbies. If you don't like to fight the traffic, then you probably won't like the job.
I spent a lot of time this year multitasking. There is a meeting this afternoon that I simply must attend? Grab the laptop and try to get a little light work done in the back. When in the office, I'd be working on some task with frequent context switches out for whatever phone call or walk-in visitor arrived. Soon I learned the myth of multitasking, illustrated by this photo from 43 Folders:
It's a mirage, tempting as it may be. Context switching has a measurable deleterious effect on my performance.
Perhaps one day I can reach a state of Zen mind in which I can live this recommendation from Ron Rolheiser:
Henri Nouwen once wrote "I used to get upset about all the interruptions to my work until one day I realized that the interruptions were my real work."
Pure earthily accidents often do make us responsible for what is divine and they conscript us to our real work.
I do realize that at least part of my job is to fight the traffic, to make the lives of the faculty and students better in the process. But on too many days it all just feels like an unending distraction. Part of my task now is to learn how to manage this flow of needs and wants better, and another part is to learn what part of this flow really is my real work.
So my answer to all my friends and colleagues is, I'm still doing the dance of joy at semester's end, but for a different reason. I'm looking forward to a couple of months in which to collect my thoughts, work at a steadier pace, internalize a few lessons from the year, figure out how to get better -- and to hack a little Ruby or Scheme or Java, when the mood strikes me!
Our semester ended a couple of weeks ago. It was busier than usual, for a variety of reasons, but my compiler course was one of the enjoyable experiences. Of course, my students will say that my compiler course was one of the major reasons that their semester was busier than usual.
A compiler is usually the largest piece of software an undergraduate CS student will write. Some of my students may have written other large programs, in other senior project courses, but I doubt they've written larger, and certainly not in smaller teams. (Most worked in pairs.) Several commented that they learned more just trying to write such a large program than they had in any of my courses. That doesn't surprise... It's one of the main reasons that I think it's essential for every undergrad to take a project course of this sort. There is no substitute.
After watching my students struggle to meet deadlines and to deliver assigned functionality, I've been thinking about using agile methods to write a compiler. Even with occasional suggestions from me for how to manage their projects, students fell behind. It is just too easy for students to fill their time with other, more immediate demands and watch project deadlines such as "table-driven parser, due in three weeks" get closer and closer.
Then there were times when students made a good-faith effort to estimate how long a task would take them, only to be off by an order of magnitude. The code for the table-driven parser isn't so bad, but, boy, does that table take a long time to build!!
Throughout the semester, I made several common suggestions, ones that will sound familiar: take small steps through the spec; have unit tests for each element you build, so that you won't be so afraid to make changes. But next time, I think I may go one step farther and make two other agile practices cornerstones of the course: short iterations and small releases. How about a deliverable every week!?
Figuring out how best to define the stories and then order them for implementation will be the challenge. In my mind's eye, I'd like for each release to create a complete compiler, for some linguistically meaningful definition of "complete". Start with such a subset of the language that we can build a compiler for it with little or no overhead. Then, add to the language grammar bit by bit in ways that slowly introduce the ideas we want to study and implement. Eventually we need a more principled form of scanning; eventually, we need a parser that implements a derivation explicitly. The issues would not have to arise in the traditional front-to-back order of a compiler course; why do we necessarily have to build a fancy parser before implementing a rudimentary run-time system?
Can this work for something like the parsing table? Adding grammar elements to the language piecemeal can have odd effects on the parsing rules. But I think it's possible.
And if I seem stuck on the table-driven parser in all of my examples, this may be a result of the fact that I still like for students to implement their parsers by hand. I know that we could go a lot farther, and do a lot more with code generation and optimization, if we built our parsers using a tool such as Yacc, JavaCC, or SableCC. But I can't shake the feeling of the value that comes from implementing a non-trivial parser by hand. Maybe I'm a dinosaur; maybe my feelings will change in the next eighteen months before I teach the course again.
Though I've been thinking some of these thoughts since last summer, I have to give credit to Jeremy Frens and Andrew Meneely of Calvin College, who presented a paper at this year's SIGCSE called Fifteen Compilers in Fifteen Days (also available from the ACM Digital Library). I'm not sure I'd want to follow their course outline very closely, but they do have some experience in sequencing the stories for the project in a way that introduces complexities in an interesting way. And the idea is just what I think we need: fifteen compilers in fifteen weeks.
It's been so long since I wrote regularly here that I am starting to feel a sense of withdrawal. Rather than try to tackle a larger essay today, I'm going to ease my way back in with one small lesson I have learned this year while trying to be an effective department head.
When I was a teenager, I read a science-fiction story about a man from Earth who traveled to a distant planet populated by folks who were mostly like us. They differed in one substantial way: they took on the emotions of those around them. When the Earth traveler was happy, so were the alien folks with whom he lived. When he was in a foul mood, they were, too. When he was sad, they, too became sad. The protagonist fell in love but ultimately had to leave the planet, because he could not bear to inflict his own moodiness and depressions on his lover, who seemed to suffer so much more than he did.
No, I haven't developed supernatural empathic abilities, but I did learn the value of not being too sensitive. It's not good for my health, and surprisingly not good for those around me.
The part about my health is pretty straightforward. In an administrative position, there are lots of people who depend on one's performance and who can become unhappy with results. Teachers always face this, through their students, but students are a remarkably resilient bunch. They are perhaps more used to not being in control of their worlds and so are less likely to cause a fuss when things don't go perfectly.
Faculty and other administrators aren't always so happy-go-lucky. Don't get me wrong; it's not that faculty and administrators are more likely to complain. It's just that they depend on other folks in order to get their own work done and so are more sensitive to conditions that differ from expected. And they are more likely to be direct in their comments.
Over a decade of participating in the software patterns community and its writers' workshop format, I've increasingly come to appreciate the value of providing positive and constructive feedback in a supportive way. I've been fortunate this year to have several colleagues who were willing to give me feedback about my performance that I need in order to get better. But a blunt listing of "here are things that haven't gone as well as we had hoped" can be quite a downer. It's easy to tell oneself not to be too sensitive; it's a much taller order not to be too sensitive. The ethos of writers' workshops is one of shared commitment to growth and so creates as supportive framework as possible in which to deliver suggestions.
Luckily, I think I've avoided being defensive in the face of criticisms -- most of which are accurate, and the rest of which are at least understandable from the perspective of the speaker -- but that doesn't make the sound of them any less of a drag on the psyche.
How does oversensitivity affect others? First of all, folks who are feeling down are less likely to do really good work for the team. Until my mood bounces back, I feel like a substandard performer. Second, oversensitivity creates a reluctance to open up so easily, which makes the person a less effective collaborator. I think I've been lucky to avoid this pitfall so far this year, but it requires conscious effort.
I hope that I am able to fold this lesson back into how I give feedback to my colleagues and in the classroom. Constructive suggestions are more likely to help the hearer if they arrive in a supportive package.
P.S. If you have any idea of the name or author of the story I described above, please drop me a note.)
Sometime in the last month, I came across a link to an article that is a couple of years old, Why Good Programmers Are Lazy and Dumb. I like to read that kind of article every once in a while, even if I've seen the general ideas before. Usually, such an article hits me in a particular way according to my current frame of mind. Here are the ideas that stood out for me this weekend:
But you can't be so lazy that you are unwilling to write those tools, or to refactor your code, to save time in the future. You have to be forward-thinking lazy. You Aren't Gonna Need It is an admonition against doing work too soon. But sometimes, you do need it.
But you can't be so dumb that you don't have the raw material out of which to propose a radical solution. You can only think outside the box when you start with a box.
Just as it's true that if you can't handle the right kind of pain you'll have a hard time getting better at much of anything, it's true that if you can't find the balance between the rights kind of lazy and dumb, you'll have a hard time taking your skills to the next level.
I was in Portland this weekend for the spring meeting of the OOPSLA 2006 conference committee. This is the meeting where we assemble the program for the conference, from technical papers to lightning talks to invited and keynote talks, from Onward! to the Educators' Symposium to DesignFest, from workshops to area of responsibility this year, tutorials. It looks like we will have 57 tutorials this year, covering a range of topics in the OOP community and out in the industrial software development community. It's a tough job to assemble the elements of such a program, which ranges over five days and encompasses affiliated events like GPCE and, for the first time ever this year, PLoP. Trying to schedule events in such a way as to minimize the number of times conference attendees say, "Rats! There are two things I want to see right now. In the session before lunch, there were none!" I suppose that, in some way, we'd be happy if every session created a conflict for attendees, but I'm not sure the attendees would like it so much!
As I've done in the past when chairing the 2004 and 2005 Educators' Symposia, I owe a great debt to my program committee of seven OOPSLA veterans. They did most of the heavy lifting in reading and evaluating all of the submissions we received. I had to make some tough calls at the end, but their input made that doable.
Some highlights from the weekend:
PDX, the Portland International Airport, has free wireless -- with better coverage than promised. Hurray!
Why is Onward! is a must-see? So that you can "cool your pinkies in the mud of the future". Maybe it's a must-see because the chairs of Onward! are the kind of people who say such things. I'm especially looking forward to Onward! films, which I had to step out of last year.
I am not sure that my students are ready for a web page about me that looks like this pictorial biography of past OOPSLA chair Douglas Schmidt. My favorite is this take on the old cartoon standard about the evolution of man:
You may recall me commenting on a particular sign I saw while running in Portland back at the fall meeting. Doesn't it always rain in Portland? Maybe not, it rained again both nights and mornings I was there this time. It was nice enough when I arrived Friday evening, if cool, and the sun had poked through the clouds Monday afternoon -- as we left.
At least it didn't rain on me while I ran. Unfortunately, I was only able to run my first morning in town. It was my first 12-miler in eight weeks or so, and felt pretty good. But, just as I did the second day at SIGCSE and the second day at ChiliPLoP I came down with some sort of respiratory thing that sapped all of my energy. So I took today off, and probably will tomorrow, too, just to get back to normal. I have a feeling that I won't be bragging about my mileage the year like I did at the end of 2005... I'm beginning to wonder about the pattern and what I can do make air travel workable again for me. I won't have a chance to test any hypothesis I develop until October, when I go to PLoP and OOPSLA.
Finally, on a less frivolous note, we spent a few minutes on Monday morning to plan a memorial for John Vlissides, whose passing I memorialized last winter. We want this memorial to be a celebration of all the ways John touched the lives of everyone he met. In an e-mail conversation last week, 2006 Educators' Symposium chair Rick Mercer pointed out a picture of John and me that I didn't know about from John's wiki, courtesy of Dragos Manolescu.
I remember that moment clearly. It has an OOPSLA connection, too, because it was taken at the annual fall meeting of the Hillside Group, which traditionally takes place the evening and morning after OOPSLA. (I've missed the last two, because the night OOPSLA ends is the traditional celebration dinner for the conference committee, and I've been eager to get home to see my family after a week on the round.)
John and I were part of a break-out group at that Hillside meeting on the topic of how to create a larger world in which to publish some of the work coming out of the PLoPs. Most academic conferences are places to publish novel work, and most pattern work is by definition not all that new -- it documents patterns we see in many existing code bases. The pattern as a literary work and teaching tool is itself novel, but that's just not what academic program conference committees are looking for.
Anyway, John and I were brainstorming. I don't remember what we produced in that session, but my clueless expression indicates that at that particular moment John was the one producing. That is not too surprising. yet he made me feel like an equal partner in the work. I guess I didn't hurt his impression of me too much. When he became general chair of OOPSLA 2004, he asked me to get involved with the conference committee for the first time, as his Educators' Symposium chair. Good memories. Thanks for the pointer to the photo, Rick. And thanks, Dragos, for taking the photo and sharing it.