Knowing and Doing

As we close out 2005, an article in MSU Today reminds us why scientists have to run experiments, not just sit in their easy chairs theorizing. A group of physicists was working on a new mix of quarks and gluons. Their theory predicted that they were creating a plasma with few or no interactions between the particles. When they ran their experiments, they instead "created a new state of matter, a nearly perfect fluid in which the quarks and gluons interact strongly." Gary Westfall, the lead MSU researcher on the project, said,

What is so incredibly exciting about this discovery is that what we found turned out to be totally different from what we thought we would find. ... But it shows that you cannot just rely on making theories alone. In the end, you have to build the machine and do the experiment. What you learn is often more beautiful than the most vivid imagination.

Folks who don't write computer programs often say that computers only do what we tell them to do, implying somehow that their mechanistic nature makes them uninteresting. Anyone who writes programs, though, has had the sort of experience that Gary Westfall describes. What we learn by writing a program and watching it is often more beautiful than anything we could ever have imagined.

I love this game.

Best wishes to you all for a 2006 full of vivid imagination and beautiful programs.

I've noticed an interesting disconnect between student behavior when in the role of student and when in the role of software developer.

When they are in the role of developer, students often fight the idea of XP's small steps: breaking tasks into small, estimable steps, writing a test for each small step, and then making sure the code passes the test before thinking about the next step. They want to think ahead, trust their experience and "intuition", write a lot of code -- and only then compile, run, and test the code. The testing is usually sloppy or, more charitably, incomplete -- at least in part because they are champing at the bit to move on to more code.

Is this merely a matter of habit they have developed in past CS courses? Or have their years in the K-12 educational system encouraged them to rush headlong into every problem? Perhaps it is our natural human state.

... but when in the role of student, students tend behave much differently. They want feedback -- now. When they turn in an assignment, they want the graded result as soon as possible.

I used to have a serious Grading Avoidance Problem, and all my students disliked it. Students who were otherwise quite happy with my course became cranky when I fell behind in returning assignments. Students who were unhappy with the course for other reasons, well, they became downright hostile.

I'm mostly over this problem now, though I have to be alert not to backslide. Like a recovering addict, I have to face each day anew with resolve and humility. But I have a colleague for whom this issue is still a major problem, and it creates difficulties for him with his students.

I can't blame students for wanting graded items back quickly. Those grades are the most reliable way they have of knowing where they stand in the course. Students can use this feedback to make all sorts of decisions about how and how much to study. (I do wish that more students paid more attention to the substantive feedback on their assignments and tried to use that information to improve their technique, to guide decisions about what to study.)

So: students like frequent feedback to guide their studies.

Many students also seem to prefer small, discrete, and detailed tasks to work on. This is especially true of students who are just learning to program, but I also see it in juniors or seniors. Many of these upper-division students do not seem to have developed confidence in their ability to solve even medium-sized problems. But when they are given a set of steps that has already been decomposed and ordered, they feel confidence enough to get the job done. They are industrious workers.

Confessions of a Community College Dean captured my feeling about this feature of today's students when it said, "As a student, I would have been insulted by this approach. But they aren't me." I myself enjoy tackling big problems, bringing order to an unruly mass of competing concerns. Had I always been spoon-fed toy problems already broken into nearly trivial pieces, I wonder if I would have enjoyed computer science as much. I suspect I might have because, like many people who are attracted to CS, I like to create my own problems!

So: students like to work on small, well-developed tasks whose boundaries they understand well. This, too, helps students focus their study.

My net acquaintance Chad Orzel, a physicist at Union College, speculates on why students prefer to work in this way. The conventional wisdom is that working on many small, discrete tasks encourages them to keep up with their reading. But I think he is right when he takes this diagnosis one step further: This style of course helps students to compensate for poor time management skills. Larger, less well-defined units require students to figure out what the subtasks are, estimate how long each will take, and then actually do them all in a timely fashion. By structuring our courses as a set of smaller, discrete tasks, we do much of the preparatory work for our students. When students are first learning, this is good, but as they grow (or should be growing) we are merely reinforcing bad habits.

It seems that we professors are enablers in a system of codependency. :-)

Even in this regard, the relationship between student as software developer and student as student holds. As I have written before, software methodologies are self-help systems. Perhaps so are the ways we structure problems and lectures for our students.

Once again, I can't blame students for preferring to work on small, discrete, well-defined tasks. Most people work better under these circumstances. Even those of us who love the challenge of tackling big problems usually succeed by taming the problem's complexity, reducing it to a system of smaller, independent, interacting components. That's what design is.

Students need to learn how to design, too. When students are getting started, professors need to scaffold their work by doing much of the design for them. Then, as students increase in knowledge and skill, we need to pull the scaffolding away slowly and let students do more and more of their own design. It's easy for professors to fall into the habit of finely specifying student tasks. But in doing this thinking for them, we deny them the essential experience of decomposing tasks for themselves.

Maybe we can leverage the agile-facing side of student behavior in helping them to develop agile habits as software developers. People aren't always able to change their behavior in one arena when they come to see that it is inconsistent with their behavior in another; we aren't wired that way. But knowing ourselves a little better is a good thing, and creates one more opportunity for our mind to grow.

(I doubt going the other way would work very well. But it might take away some of the pressure to grade work quickly!)

My only non-professional blog category is on running. That reflects one of my primary personal interests in the time since I started blogging a year and a half ago. If I had started blogging twenty-five years ago, the extra category would have been on chess.

From grade school into college, but especially in high school, I played a lot of chess, more than anyone I knew. I read chess books, I played chess variants, and I surrounded myself with the miscellania of the chess world. Chess didn't seem especially popular in the late 1970s and early 1980s, but we were still in the midst of the Fischer boom, which had created a resurgence in the popularity of chess in America. The headiness of the Fischer boom years eventually passed. Independently, I got busy at college with computer science (and girls) and had less and less time to play. But I still love the game.

A recent article in the New York Times talks about the further decline of American chess. The article's author, Jennifer Shahade, is a former U.S. women's champion and one of only a few young native-born Americans to have accomplished much in the world of chess over the last decade. There are many great minds who still play chess in the U.S. when they are young, but they are pulled toward more attractive -- and lucrative -- endeavors as they get older. Shahade points to poker, which has undergone a massive boom in popularity over the last decade, as a source of possible ideas for saving chess from its decline.

Her suggestions are reasonable goals accompanied by simple strategies for reaching them. The chess world needs to offer ways for adults to learn the game effectively on-line and to promote the sporting, competitive element of chess. (And I can support Shahade's claim that a long tournament game of chess is much more tiring than many physical activities.) But ultimately the key is finding a way to make chess seem cool and exciting again. A breakthrough on the world stage by a player like Hikaru Nakamura could turn the trick, but it's hard to engineer that sort of event.

Others interested in promoting chess have adopted more, um, salacious methods. Consider the World Chess Beauty Contest, reported in another NYT article on the same day as Shahade's. The WCBC tries to draw people -- well, at least teenage boys -- to chess by focusing on the many beautiful young women chess players around the world. When you are looking at pictures of these young ladies, just don't forget this: most of them are really strong players who can easily defeat the vast majority of chessplayers in the world. But, for the most part, they are not competitive with the very best women players in the world, let alone the top men.

Still, the thought that supermodel Carmen Kass is an avid chess player, is president of the Estonian Chess Federation last year, and is dating German grandmaster Eric Lobron makes me secretly happy. (The above picture is from the second NYT article and shows Kass playing speed chess with Indian super-grandmaster Viswanathan Anand, the world's #2 player.)

Shahade talks about how we could heighten interest in chess tournaments by making them more thrilling, more immediate. Chess tournaments are usually arranged as round-robin or Swiss system affairs, neither of which tends to create do-or-die situations that heighten in intensity as the tournament progresses. In contrast, consider U.S. college basketball's March Madness -- and then imagine what it would be like as as a round-robin. Boring -- and much less variable in its outcome.

We all love the mere chance that a Princeton or a UNI will come out of nowhere to upset a Duke or an Indiana, even if it doesn't happen very often. But in chess, the chances of a much lower-ranked player upsetting a better player is quite small. The standard deviation on performance at the highest levels of chess is remarkably small. When you try to cross more than one level, forget it. For example, the chance that I could beat Gary Kasparov, or even earn a draw against him, is essentially zero.

My proposal to increase the competitiveness of games among players of different skill levels comes from the 19th century: odds. Odds in chess are akin to handicaps in golf. For example, I might offer a weaker player "pawn odds" by removing my king's bishop's pawn before commencing play. In that case, I would probably play the white pieces; if I gave pawn odds and played black, then I would be giving "pawn and move" odds. (Moving first is a big advantage in chess.)

Back in the 1800s, it was common for even the best players in the world to take odds from better players. America's first great chess champion, Paul Morphy made his reputation by beating most of America's best players, and many of Europe's best players at "pawn and move" odds.

Since the advent of the chess clock, another way to handicap a chess game is to give time odds. I spent many an evening as a teenager playing speed chess with Indianapolis masters who gave me the advantage of playing in 1.5 minutes against my 5 minutes. Even at those odds, I lost more quarters than I won for a long time... But I felt like I had a chance in every game we played, despite the fact that those guys were much better than I was.

My experience offering odds has been less successful. When I've tried to offer time odds to students and former students, they balked or outright refused. To them, playing at advantage seemed unsporting. But the result has generally been one-sided games and, within a while, one or both of us loses interest. I've never tried to give piece odds to these folks, because material seems more real to them than time and consequently the odds would seem even less sporting.

Odds chess isn't the complete answer to making top-level chess more attractive, though it might have its place in novelty tournaments. But giving odds could make coffeehouse chess, casual games wherever, and local tournaments more interesting for more players -- and thus offer a route to increased popularity.

This whole discussion raises another, more fundamental question. Should we even care about the popularity of chess? The conventional wisdom is yes; chess is a fun way for kids to learn to concentrate, to think strategically, to learn and deploy patterns, and so on. There is some evidence that children who play chess realize benefits from these skills in school, especially in math. But in today's world there are many more challenging and realistic games these days than there used to be, and maybe those games -- or learning to play a musical instrument, or learning to program a computer -- are better uses for our young brainpower. As a lover of the game, though, I still harbor a romantic notion that chess is worth saving.

One thing is for certain, though. Poker is a step backwards intellectually. It may be a lot of fun and require many useful skills, but it is much shallower than chess, or even more challenging card games, such as bridge.

The article on Jennifer Shahade that I link to above ends with a paragraph that sums up both the challenge in making chess more popular and a reason why it is worth the effort to do so:

"People sometimes ask me if chess is fun," Jennifer says. "'Fun' is not the word I'd use. Tournament chess is not relaxing. It's stressful, even if you win. The game demands total concentration. If you mind wanders for a moment, with one bad move you can throw away everything you've painstakingly built up."

Modern society doesn't seem to value things that aren't always fun and light, at least not as much as it could. But we could do our children a favor if we helped them learn to concentrate so deeply, to confront a challenge and painstakingly work toward a solution.

Maybe then math and science -- and computer programming -- wouldn't seem unusually or unexpectedly hard. And maybe then more students would have the mental skills needed to appreciate the beauty, power, and, yes, fun in work that challenges them. Like computer science.

Yesterday I received e-mail from the chair of a CS education conference. For some reason, this snippet caught my eye:

We encourage you to visit the conference website
[URL]
on a regular basis for the latest information about [the conference]."

My first thought was, "You need an RSS feed!" I am not very good about remembering to check a web site on a regular basis, at least in part because there are so many web sites in which I am interested. The result: I tend to miss out on the latest information. But with a subscription feed, my newsreader reminds me to check the sites that have new content.

And this e-mail was for a conference in computer science education. A conference of techies, right? Why haven't they joined the 21st century?

My second thought was, "Physician, heal thyself!" I do the same thing to my students. Here is a snippet from the home page for my fall course:

Welcome to your portal into the world of 810:154 Programming Languages and Paradigms. These pages will complement what you find in class. You will want to check the "What's New" section often -- even when I don't mention changes in class -- to see what is available.

Can I really expect students to check the site on their own? At least I put up lecture notes (with code) twice a week and homework once a week to create some 'pull'. But students are pulled in many different directions, and maybe a little push would help.

This raises a question: How many of my students use a newsreader or RSS-enable web browser these days? Offering a news feed will only improve the situation if these folks take advantage of the feed. So I will have pushed the problem from one required habit to another, but at least it's a habit that consolidates multiple problems into one, and a habit that is growing in its reach. But beginning next semester, I'll ask my students if and how they use news feeds, and encourage them to give it a try.

And I will offer a feed for my course web site. Perhaps that will help a few students stay on top of the game and not miss out on the latest information.

You would think that we computer scientists would not be so behind the technological curve. Shouldn't we be living just a bit in the future more often? You know what they say about the cobbler's children...

Electron Blue recently wrote about some of her experiments in art. As an amateur student of physics, she knows that these experiments are different the experiments that scientists most often perform. She doesn't always start with a "hypothesis", and when she gets done it can be difficult to tell if the experiment was a "success" or not. Her experiments are opportunities to try ideas, to see whether a new technique works out. Sometimes, that's easy to see, as when the paint of a base image dries with a grainy texture that doesn't fit the image or her next stage. Other times, it comes down to her judgment about balance or harmony.

This is quite unlike many science experiments, but I think it has more in common with science than may at first appear. And I think it is very much like what programmers and software developers do all the time.

Many scientific advances have resulted from what amounts to "trying things out", even without a fixed goal in mind. On my office wall, I have a wonderful little news brief called "Don't leave research to chance", taken from some Michigan State publication in the early 1990s. The article is about some work by Robert Root-Bernstein, an MSU science professor who in the 1980s spent time as a MacArthur Prize fellow studying creativity in the sciences. In particular, it lists ten ways to increase one's chances of serendipitously encountering valuable new ideas. Many of these are strict matters of technique, such as removing background "noise" that everyone else accepts or varying experimental conditions or control groups more widely than usual. But others fit the art experiment mold, such as running a reaction backward, amplifying a side reaction, or doing something else "unthinkable" just to see what happens. The world of science isn't always as neat as it appears from the outside.

And certainly we software developers explore and play in a way that an artist would recognize -- at least we do when we have the time and freedom to do so. When I am learning a new technique or language or framework, I frequently invoke the Three Bears Pattern that I first learned from Kent Beck via one of the earliest pedagogical patterns workshops. One of the instantiations of this pattern is to use the new idea everywhere, as often and as much as you can. By ignoring boundaries, conventional wisdom, and pat textbook descriptions of when the technique is useful, the developer really learns the technique's strengths and weaknesses.

I have a directory called software/playground/ where I visit when I just want to try something out. This folder is a living museum of some of the experiments I've tried. Some are as mundane as learning some hidden feature of Java interfaces, while others are more ambitious attempts to see just how far I can take the Model-View-Controller pattern before the resulting pain exceeds the benefits. Just opportunities to try an idea, to see how a new technique works out.

My own experience is filled with many other examples. A grad student and I learned pair programming by giving it a whirl for a while to see how it felt. And just a couple of weeks ago, on the plane to Portland for the OOPSLA 2006 fall planning meeting, I whipped up a native Ook! interpreter in Scheme -- just because. (There is still a bug in it somewhere... )

Finally, I suspect that web designers experiment in much the way that artists do when they have ideas about layout, design, and usability. The best way to evaluate the idea is often to implement it and see what real users think! This even fits Electron Blue's ultimate test of her experiments: How do people react to the work? Do they like it enough to buy it? Software developers know all about this, or should.

One of the things I love most about programming is that I have the power to write the code -- to make my ideas come alive, to watch them in animated bits on the screen, to watch them interacting with other people's data and ideas.

As different as artists and scientists and software developers are, we all have some things in common, and playful experimentation is one.

I'm approaching the end of my first semester as head of my department. And a busy end to the semester it's been! As I have some time reflect on the last few months, I will have a few things to say about heading a department, the state of computer science and CS education, and the effect of moving to the Big Office Downstairs on my own computer science. For now, I have noticed a couple of things that surprised me a bit

First, no matter how much I planned ahead about management style, I have found myself developing my style as I go.

For example, I find myself regularly sending out long-ish e-mail "memos" to the faculty, and occasionally even to students. Often, these messages aim to jump start a discussion that will continue over time and perhaps culminate in faculty meetings. Other times, I write just to share what I've learned in the various meetings I attend.

I am not alone in this style. Last week, I went to a final public lecture by one of our retiring professors of mathematics, in which he reminisced on 42 years on the faculty here. This gentleman was department head in Mathematics through important years: he was head when the department developed its computer science curriculum and then its first majors, and he was head when Math made plans to spin us off into the the new Department of Computer Science I joined in 1992. In his talk, he told of his habit of writing memos of many pages for his colleagues, typing them up, duplicating them with an old-style mimeograph machine, and placing them in faculty mailboxes. I send my memos to faculty mailboxes, too, but of the electronic variety. And the only duplication I have to do is accomplished when I press the Send button to a faculty mailing list. How much more laborious it was to communicate this way back in the 1970s! Yet David went to the effort, because he, too, felt the worth in sharing information and ideas. In such communication, he empowered his faculty and made them an integral part of the department's progress.

I produce my messages on a more modern contraption. The only real cost I must pay is the time it takes me to write. But, as with this blog, the writing is valuable to me before anyone else even reads the result. I am usually writing to learn, to remember what I've heard and assimilate it into my working knowledge. These messages also serve as a written record, for me and for others, of what has happened. Let's just say this: If I'm ever nominated for the Supreme Court, there will be one heckuva paper trail for my opponents to follow!

Second, it is hard to overestimate the importance of communication.

As I have become involved in matters of evaluating faculty, handling student complaints, and negotiating with other departments on campus for space, money, and other resources, I have found myself spending a lot of energy on speaking and writing clearly and directly. I would have thought that I already had good habits in this regard, from all my years in the classroom. But the effects of ambiguity and miscommunication are more immediately obvious in supervisory activity with faculty and interactions with higher-level administrators. Within a few weeks I noticed that I was stopping and thinking before speaking, in an effort not to say something I would immediately have to explain or undo.

How can I speak the truth in the department's best interest, both short- and long-term? Making clear points with as little ambiguity as possible is essential. This seems to work best as part of a rich relationship among people, so that honesty can be trusted as fair. When communication happens in an unconstrained context, there is simply to much room for confusion.

(On a more technical note... I've noticed this concern for clarity and directness bleeding over into my programming. As I wrote code for my programming languages course this semester, I kept asking myself, "Does this code say what I want it to say?" The result was that I rewrote a lot of old code and crafted new code with greater care. I even occasionally used a comment -- gasp! -- when I used an idiom with which my students weren't familiar. I'm pleased with the results.)

In addition to speaking clearly and directly, I have learned that I want to speak fairly. Consider the task of personnel evaluation. An evaluation of an employee's performance is a deeply personal event for the employee. Without some care, it is easy to write the evaluation in a way that focuses on negatives. And to the person being evaluated, even a balanced letter can feel more negative than it is -- the negative comments appear to be much bigger than they are in comparison to the positives. Our minds trick us with an inverted perspective.

I've found that writing evaluations is a deeply personal event for me. "Personnel" are people. In my case, these folks are my friends and colleagues of many years. I want to write evaluations that clearly and fairly express the person's contribution to our department and the ways in which he or she might improve. Again, this works best in the rich context of a relationship. Maintaining good relationships is an essential element of the new administrator's success.

Some have suggested that I should be more irascible, as a way to command attention, but that's not my style. I'd rather think of even the more contentious interactions as part of a long-term relationship. I realize that there will likely soon come a time when I have to be a hard guy and make a fast stand, but I'd rather save that approach for when it's really needed. By then, my usual demeanor will be what people expect, and my making stand is more likely to attract attention to the seriousness of the issue.

Being fair is in everyone's best interest. I sometimes try to be a mediating force, to help folks see that they don't have to be mean to make their point -- indeed, that the best way to have one's point heard and taken seriously is to be direct but fair. This is not always easy, but I think it is worth the effort. It helps us to build strong relationships, and it pays off by letting the people I work with be partners in moving the department forward.

The end of my semester has been busier than usual, which has made it difficult for me to set aside time to read, write, or rest much. So I was happy to have the luxury of an hour on Saturday to run the 2005 Snow Shuffle 5K. This is the 5th annual Snow Shuffle, which brings the local racing season to a close with a relatively relaxed run and plenty of doughnuts and hot chocolate.

Back in November, I wrote:

Now I am getting excited about running the Snow Shuffle 5K on December 10. It's tough to PR races in the cold of December, and there is always the chance of snow or ice or fierce wind. So I won't plan for anything other than running as fast as the conditions allow. But the thought of racing, however short, sounds good again.

In the intervening few weeks, I had not felt all that fast, either on the road or the track, so I had decided to make this a fun run. I even ran laps on Wednesday, three days before the race, as a way to reduce any temptation to expect anything out of the race.

The super cold weather of last week passed, but in its place we received several inches more snow, for a total of 13" or more on the ground. So race day saw temperatures in the teens Fahrenheit and plenty of slush and ice on the course. My expectations were lowered even further.

But I felt good. My early pace was faster than my usual fast runs, and I finished the first mile in 6:31 -- my second fastest 5K mile ever, after the first mile of my June race. I slowed a bit in the second mile, to 6:42, but with a little push I was able to maintain this pace... and finally, with about a half mile to go, I caught a guy who had been running just ahead of me for over a mile. He cheered me on and, though I didn't have the legs to accelerate, I held on.

My official time was 20:46, with a course time of 20:44 -- a PR by over five seconds. I was a happy guy.

Maybe it helps train in the winter weather of Iowa after all.

Even more amazing to me than my 2nd place in the 40-49 age group is that I finished in the top ten overall, out of 150+ finishers. I'm not sure I have ever finished as high as 9th in a race that had more than nine people in it!

This race buoys my spirits a bit, both for running and for the end of our academic term. I have much that I would like to write about the last few weeks, and now I can see the finish line of the semester, at which I will be able to indulge in a little reading and writing.

You might be a runner if...

1. ... you get back from your morning run to find that the temperature has risen to 12 degrees.

   Fahrenheit.

   Below zero.

2. ... you make plans to go to your office to do some work that will take the rest of the day, so you schedule your daily run for just before you go in.

   At 4 o'clock.

   AM.

   And it is cold. (Go to #1.)

With apologies to Jeff Foxworthy. (Though my colleagues in the office are more likely to offer me a sign, courtesy of Bill Engvall.)

I teach at a "comprehensive university", one of those primarily undergraduate institutions that falls outside of the Research I classification whose schools dominate the mind share of the computer science world. After graduation, most of our students become software practitioners at companies in Iowa and the midwestern U.S.

Last spring, I was excited when one of my M.S. students became the first student at our university to receive a job offer from Google. I may not have been more excited than he was, but then again maybe I was... His thesis presented some novel work on algorithms for automatic route planning of snow removal operations, an important topic for road departments in my part of the world, and Google found him a promising developer for Google Maps. As an advisor and faculty member, I was filled with pride -- perhaps a false pride. Look at this validation of my work!

Imagine my disappointment when, for a variety of personal and pragmatic reasons, my student turned Google down. I sympathized with his difficult choice, but where's the caché for me in "I was the advisor of a student who almost worked for Google"? What about my needs?

Today my excitement was renewed when I found that a former undergraduate student of mine has accepted an offer from ThoughtWorks. In the software world, ThoughtWorks is known as one of the cooler consulting firms out there. Like Google, it seems to hire up lots of the interesting folks, especially in the OO and agile circles I frequent.

Chris approached Thoughtworks through its ThoughtWorks University program, aimed at attracting promising recent graduates. He is just the sort of student that programs like this seek: a guy who has demonstrated potential in classwork and research, even though he doesn't come from a Big-Name Institution. His undergraduate research project on the construction of zoomable user interfaces won the award for undergraduate scientific research at our university, an award that usually goes to a student in the hard sciences.

Universities like ours are a relatively untapped resource for advanced technology companies. Our best students are as strong as the best students anywhere. The only problem is that many of them don't have a big enough vision of what they can accomplish in the world. Turning their vision outward, toward entrepreneurial opportunities whether in start-ups or established firms, is the key. It's one of my major goals for our department over the next three years.

I can take some pride in knowing that my courses in object-oriented programming and agile software development probably helped this student attract some attention from the folks at ThoughtWorks, but I know that it's these students themselves who make opportunities for themselves. As an educator, my job is to help them to see just how big the world of ideas and opportunities really is.

For many, many years, my hometown of Indianapolis, Indiana, was the largest city in the United States not located on a navigable waterway. (Phoenix has that distinction now, and some other cities in the Sun Belt have probably passed Indianapolis by now, too.) My family didn't travel much when I was growing up, so I have relatively exposure to life on the water. This accounts for some of my enjoyment of water when I run at conferences. Running in Vancouver is still among my favorites.

I'm in Portland today for the OOPSLA 2006 fall planning meeting. This is my first trip to Portland, and naturally the first thing I did this morning was to hit the road for a pre-dawn run. 5:00 AM here is 7:00 AM on my body's clock, so that was easier than it sounds.

Portland is defined in large part by its water source, the Willamette River, which divides the town northeast and southwest. With just one day in town, I kept my route simple, running from my hotel on the northeast side of the river to a 3-mile loop up and down a riverwalk in the downtown area. It was a nice mix of scenic riverwalk and the sort of gritty area that I seem to experience in water towns.

I had a couple of fun new experiences this morning...

• drawbridges

  I've seen drawbridges before, and even driven over a cool little manual drawbridge on Cape Code. But this may have been the first time I've run over one -- and I ran over two. The first was an auto bridge of the traditional sort:

  

  But imagine my surprise when I began my second lap across the river, where the pedestrian walk parallels a railroad track, and ran into a closed gate that had not been there on my first pass... and the bridge was just gone! Well, it wasn't gone so much as 30 feet in the air:

  

  I was so caught up in marveling at this feat of technology that I didn't notice how cool I became as I waited for the bridge to come back down. Standing still in 35-degree rainy weather during a run can be that way...

• Warning!

  It didn't rain while I ran, but it had rained through the night. That, and the Pacific Northwest's reputation for rain, rain, rain, made one warning sign I encountered all the more humorous:

  Warning!    Sewage    Avoid contact with river after rain

  Hasn't it always just rained in Portland?

I enjoyed my morning run so much that I may skip the conference committee dinner this evening and try a different route... More on the conference itself tomorrow.

My friend Kris Anderson sent e-mail in response to my entry on I = k|P|. Here's part of what he said:

So then, I got to thinking about the variable "|P|" in your equation. Absolute value? As I thought about it, Aerosmith's "Dream On" started playing in my head... "Live and learn from fools and from sages..." 'Fools' represent negative values and 'Sages' represent positive values. And since the lesson one can learn from either is of equal value, that's why 'P' must be '|P|'. Very cool.

As I told him, Now that is cool. When I wrote my message, by |P| I meant the cardinality of the set P. Kris took P to mean not a set but the value of some interaction, either positive or negative. The ambiguous |P| then can indicate that we learn something of value from both positive influences and negative influences, like positive and negative examples in induction. I think that I'll stick with my original intention and leave credit for this re-interpretation to Kris.

And who knew that anyone would read my entry and make a connection to Aerosmith? Different people, different familiar ideas, different connections. That reminds of something Ward Cunningham said at OOPSLA 2005.

I learn so much from other folks reading what I write -- yet another example of the point of the article.