Knowing and Doing

A former student recently mentioned a tough choice he faces. He has a great job at a Big Company here in the Midwest. The company loves him and wants him to stay for the long term. He likes the job, the company, and the community in which he lives. But this isn't the sort of job he originally had hoped for upon graduation.

Now a position of just the sort he was originally looking for is available to him in a sunny paradise. He says, "I have quite a decision to make.... it's hard to convince myself to leave the secure confines of [Big Company]. Now I see why their turnover rate is so low."

I had a hard time offering any advice. When I was growing up, my dad work for Ford Motor Company in an assembly plant, and he faced insecurity about the continuance of his job several times. I don't know how much this experience affected my outlook on jobs, but in any case my personality is one that tends to value security over big risk/big gain opportunities.

Now I hold a job with greater job security than anyone who works for a big corporation. An older colleague is fond of saying Real men don't accept tenure. I first heard him say that when I was in grad school, and I remember not getting it at all. What's not to like about tenure?

After a decade with tenure, I understand better now what he means. I always thought that the security provided by having tenure would promote taking risks, even if only of the intellectual sort. But too much security is just as likely to stunt growth and inhibit taking risks. I sometimes have to make a conscious effort to push myself out of my comfort zone. Intellectually, I feel free to try new things, but pushing myself out of a comfortable nest here into a new wnvironment -- well, that's another matter. What are the opportunity costs in that?

I love what Paul Graham says about young CS students and grads having the ability to take entrepreneurial risk, and how taking those risks may well be the safer choice in the long run. It's kind of like investing in stocks instead of bonds, I think. I encourage all of my students to give entrepreneurship a thought, and I encourage even more the ones whom I think have a significant chance to do something big. There is probably a bit of wistfulness in my encouragement, not having done that myself, but I don't think I'm simply projecting my own feelings. I really do believe that taking some employment risk, especially while young, is good for many CS grads.

But when faced with a concrete case -- a particular student having to make a particular decision -- I don't feel quite so cocksure in saying "go for it with abandon". This is not abstract theory; his job and home and fiancee are all in play. He will have to make this decision on his own, and I'd hate to push him toward something that isn't right for him from my cushy, secure seat in the tower. I feel a need to stay abstract in my advice and leave him to sort things out. Fortunately, he is a bright, level-headed guy, and I'm sure he'll do fine whichever way he chooses. I wish him luck.

Surround yourself with smart, competent people, and you will find ideas in the air. One of the compelling thoughts in that article is this:

A scientific genius is not a person who does what no one else can do; he or she is someone who does what it takes many others to do.

For those of us who are not geniuses, the lesson is that we can still accomplish great things -- if we take part in the right sort of collaboration and be curious, inquisitive, and open to big ideas. I think this applies not only to inventions but also to ideas for start-ups and insight to class projects.

(So go to class. You'll find people there.)

But being in a group is not a path to easy accomplishment, as people who have tried to write a book in a group know:

Talking about a "group-book" is a lot of fun. Actually putting one together, maybe less fun.

The ongoing ChiliPLoP working group of which I am a member is another datapoint for Mitzenmacher's claim. Doing more than brainstorming ideas in a groups takes all the same effort, coordination, and individual and collective responsibility as any other sort of work.

(As an aside, I love Stigler's Law as quoted in the Gladwell article linked above! Self-reference can be a joy, especially with the twist engendered by this one.)

I notice a common rhetorical device in many academic arguments. It goes like this. One person makes a claim and offers some evidence. Often, the claim involves doing something new or seeing something in a new way. The next person rebuts the argument with a claim that the old way of doing or seeing things is more "fundamental" -- it is the foundation on which other ways of doing and seeing are built. Oftentimes, the rebuttal comes with no particular supporting evidence, with the claimant relying on many in the discussion to accept the claim prima facie. We might call this The Fundamental Imperative.

This device is standard issue in the CS curriculum discussions about object-oriented programming and structured programming in first-year courses. I recently noticed its use on the SIGCSE mailing list, in a discussion of what mathematics courses should be required as part of a CS major. After several folks observed that calculus was being de-emphasized in some CS majors, in favor of more discrete mathematics, one frequent poster declared:

(In a word, computer science is no longer to be considered a hard science.)

If we know [the applicants'] school well we may decide to treat them as having solid and relevant math backgrounds, but we will no longer automatically make that assumption.

Often, the conversation ends there; folks don't want to argue against what is accepted as basic, fundamental, good, and true. But someone in this thread had the courage to call out the emperor:

If you want good physicists, then hire people who have calculus. If you want good computer scientists, then hire people who have discrete structures, theory of computation, and program verification.

I don't believe that people who are doing computer science are not doing "hard science" just because it is not physics. The world is bigger than that.

...

You say "solid and relevant" when you really should be saying "relevant". The math that CS majors take is solid. It may not be immediately relevant to problems [at your company]. That doesn't mean it is not "solid" or "hard science".

I sent this poster a private "thank you". For some reason, people who drop the The Fundamental Imperative into an argument seem to think that it is true absolutely, regardless of context. Sure, there may be students who would benefit from learning to program using a "back to the basics" approach, and there may be CS students for whom calculus will be an essential skill in their professional toolkits. But that's probably not true of all students, and it may well be that the world has changed enough that most students would benefit from different preparation.

"The Fundamental Imperative" is a nice formal name for this technique, but I tend to think of it as "if it was good enough for me...", because so often it comes down to old fogies like me projecting our experience onto the future. Both parties in such discussions would do well not to fall victim to their own storytelling.

In his recent bestseller The Black Swan: The Impact of the Highly Improbable, Nassim Nicholas Taleb uses the term narrative fallacy to describe man's penchant for creating a story after the fact, perhaps subconsciously, in order to explain why something happened -- to impute a cause for an event we did not expect. This fallacy derives from our habit of imposing patterns on data. Many view this as a weakness, but I think it is a strength as well. It is good when we use it to communicate ideas and to push us into backing up our stories with empirical investigation. It is bad when we let our stories become unexamined truth and when we use the stories to take actions that are not warranted or well-founded.

Of late, I've been thinking of the narrative fallacy in its broadest sense, telling ourselves stories that justify what we see or want to see. My entry on a response to the Onward! submission by my ChiliPLoP group was one trigger. Those of us who believe strongly that we could and perhaps should be doing something different in computer science education construct stories about what is wrong and what could be better; we're like anyone else. That one OOPSLA reviewer shed a critical light on our story, questioning its foundation. That is good! It forces us to re-examine our story, to consider to what extent it is narrative fallacy and to what extent it matches reality. In the best case, we now know more about how to tell the story better and what evidence might be useful in persuading others. In the worst, we may learn that our story is a crock. But that's a pretty good worst case, because it gets us back on the path to truth, if indeed we have fallen off.

A second trigger was finding a reference in Mark Guzdial's blog to a short piece on universal programming literacy at Ken Perlin's blog. "Universal programming literacy" is Perlin's term for something I've discussed here occasionally over the last year, the idea that all people might want or need to write computer programs. Perlin agrees but uses this article to consider whether it's a good idea to pursue the possibility that all children learn to program. It's wise to consider the soundness of your own ideas every once in a while. While Perlin may not be able to construct as challenging a counterargument as our OOPSLA reviewer did, he at least is able to begin exploring the truth of his axioms and the soundness of his own arguments. And the beauty of blogging is that readers can comment, which opens the door to other thinkers who might not be entirely sympathetic to the arguments. (I know...)

It is essential to expose our ideas to the light of scrutiny. It is perhaps even more important to expose the stories we construct subconsciously to explain the world around us, because they are most prone to being self-serving or simply convenient screens to protect our psyches. Once we have exposed the story, we must adopt a stance of skepticism and really listen to what we hear. This is the mindset of the scientist, but it can be hard to take on when our cherished beliefs are on the line.

The Small Doses pattern I wrote up in my previous entry was triggered almost exclusively by the story I heard from Carl Page. The trigger lives on in the text that runs from "Often times, the value of Small Doses..." to the end, and in the paragraph beginning "There is value in distributing...". The story was light and humorous, just the sort of story that will stick with a person for twenty or more years.

As I finally wrote the pattern, it grew. That happens all the time when I write. It grew both in size and in seriousness. At first I resisted getting too serious, but increasingly I realized that the more serious kernel of truth needed telling. So I gave it a shot.

The result of this change in tone and scope means that the pattern you read is not yet ready for prime time. Rather than wait until it was ready, though, I decided to let the pattern be a self-illustration. I have put it out now, in its rough form. It is rough both in completeness and in quality. Perhaps my readers will help me improve. Perhaps I will have time and inspiration soon to tackle the next version.

In my fantasies, I have time to write more patterns in a Graduate Student pattern language (code name: Chrysalis), even a complete language, and cross-reference it with other pattern languages such as XP. Fantasies are what they are.

Last night, I attended a Billy Joel concert. I last saw him perform live a decade or so ago. Billy was a decade older, and I was a decade older. He looked it, and I'm sure I do, too.

But when he started to play the piano, it could have been 1998 in the arena. Or 1988. Or 1978. The music flowing from his hands and his dancing feet filled me. Throughout the night I was 19 again, then 14, 10, and 25. I was lying on my parents' living room floor; sitting in the hand-me-down recliner that filled my college dorm room; dancing in Market Square Arena with an old girlfriend. I was rebellious teen, wistful adult, and mesmerized child.

There are moments when time seems more illusion than reality. Last night I felt like Billy Pilgrim, living two-plus hours unstuck in time.

Oh, and the music. There are not many artists who can, in the course of an evening, give you so many different kinds of music. From the pounding rock of "You May Be Right" to the gentle, plaintive "She's Always A Woman", and everything between. The Latin rhythms of "Don't Ask Me Why" extended with an intro of Beethoven's "Ode to Joy", and a "Root Beer Rag" worthy of Joplin.

Last night, my daughters aged 15 and 11 attended the concert with me. Music lives on, and time folds back on itself yet again.

[A transcript of the SIGCSE 2008 conference: Table of Contents]

This sort of entry usually comes after I write up the various conference sessions and have leftovers that didn't quite fit in an article. That may still happen, but I already have some sense of what will go where and have these items as miscellaneous observations.

First of all, I tried an experiment today. I did not blog in real-time. I used -- gasp! -- the antiquated technology of pen and paper to take notes during the sessions. On one or two occasions, I whipped open the laptop to do a quick Google search for a PhD dissertation or a book, but I steadfastly held back from the urge to type. I took notes on paper, but I couldn't fall into "writing" -- crafting sentences, then forming paragraphs, editing, ... All I could do was jot, and because I write slowly I had to be pickier about what I recorded. One result is that I paid more attention to the speakers, and less to a train of thought in my head. Another is that I'll have to write up the blog posts off-line, and that will take time!

As I looked through the conference program last night, I found myself putting on my department head hat, looking for sessions that would serve my department in the roles I now find myself in more often: CS1 for scientists, educational policy in CS, and the like. But when I got to the site and found myself having to choose between Door A and Door B... I found myself drifting into the room where Stuart Reges was talking about a cool question that seems to pick out good CS students, and the nifty assignments. Whatever my job title may be, I am a programmer and CS teacher. (More on both of those sessions in coming entries...)

Now, for a couple of non-CS, non-teaching observations.

• I am amazed at how many healthy adults will walk out of their way, past a perfectly good set of stairs, to ride up an escalator. Sigh.
• Staying at the discount motel over three miles away and without a car, I am relying on public buses. I have quickly learned that bus schedules are suggestions, not contracts. Deal with it. And in Portland, that often means: deal with it in the rain.
• Schoolchildren here take standard mass transit buses to school. I never knew such a place existed.

There is so much for me to learn.

With the exception of my annual visit to Carefree for ChiliPLoP, I don't often get a chance to return to a city for another conference. This year brings a pleasant return to Portland for SIGCSE 2008. OOPSLA'06 was in Portland, and I wrote up a little bit about running in Portland as part of my first visit to town. Because I was on the conference planning committee that year, I made three trips to the city, stayed in the same hotel three times, and ran several of the same routes three times. The convention center is right in town, which makes it hard to get to any nice parks to run, but Portland has a 3-mile loop alongside the Willamette River that provides a decent run.

This time, I am on my own dime and trying to save a little money by staying at a budget motel about 3.5 miles from the convention center. That meant figuring out bus routes and bus stops for the ride between the two -- no small feat for a guy who has never lived in a place where public transportation is common! It also meant planning some new runs, including a route back to the waterfront.

I arrived in town early enough yesterday to figure out the buses (I think) and still have time for an exploratory run. I ran toward the river, and then toward the convention center, until I knew the lay of the land well enough. The result was 4.5 miles of urban running in neighborhoods I'd never seen. This morning, used what I learned to get to the river, where I ran my first lap through the Governor Tom McCall Waterfront Park and the Eastbank Esplanade since October 2006. I ended up with about 8 miles under my belt, and a strong desire to return Saturday evening for three laps and what will be a 14-miler -- what would be my longest run since the Marine Corps Marathon. Let's see how I feel in a couple of days...

The rest of this week I am at SIGCSE, and I'm looking forward to seeing old friends and colleagues and to talking CS for a few days. Then on Sunday, four of us fly to Phoenix for ChiliPLoP and some intense work. This is a long time to be away from home and to miss my family, but the ideas should keep me busy.

Does it have a name?

Of course, Schadenfreude itself doesn't really have a name in English. It is a German word that means roughly delight in another person's misfortune. (However, I see that Wikipedia offers one, the 300+-year-old, apparently abandoned "epicaricacy".)

Last semester, a colleague described what struck me as the complement of Schadenfreude. He reported that one of our close friends, a retired professor here, expressed a strong unhappiness or distaste for faculty who succeeded in publishing academic papers. This matters to him because he is one of those folks. His friend came to the university in a different era, when we were a teacher's college without any pretension to being a comprehensive university. The new faculty who publish and talk about their research, she said, are "just showing off". Their success caused her pain, even if they didn't brag about their success.

This is not the opposite of Schadenfreude. That is happiness in another's good fortune, which Wikipedia tells us matches the Buddhist concept of mudita. What our friend feels inverts both the emotion and the trigger.

I don't think that her condition corresponds to envy. When someone is envious, they want what someone else has. Our friend doesn't want what the others have; she is saddened, almost angered, that others have it. No one should.

The closest concept I can think of is "sour grapes", a metaphor from one of Aesop's beloved fables. But in this story, the fox does want the grapes, and professes to despise them only when he can't reach them. I believe that our friend really doesn't want the success of research; she earnestly believes that our mission is to teach, not publish, and that energy spent doing research is energy misspent. And that makes her feel bad.

When my colleague told me his story, I joked that the name for this condition should be freudenschade. I proposed this even though I know a little German and know how non-sensical it is. But it seemed fun. Sadly, I wasn't the first person to coin the word... Google tells me that at least one other person has. You may be tempted to say that I feel freudenschade that someone else coined the term "freudenschade" first, but I don't. What I feel is envy!

The particular story that led to my discussion is almost beside the point. I'm on a mission that has moved beyond it. I am not aware of a German word for the complement of Schadenfreude. Nor am I aware of an English word for it. Is there a word for it anywhere, in English, German, or some other language?

I'm curious... Perhaps the Lazyweb can help me.

While catching up on some work at the office yesterday -- a rare Saturday indeed -- I listened to Peter Turchi's OOPSLA 2007 keynote address, available from the conference podcast page. Turchi is a writer with whom conference chair Richard Gabriel studied while pursuing his MFA at Warren Wilson College. I would not put this talk in the same class as Robert Hass's OOPSLA 2005 keynote, but perhaps that has more to do with my listening to an audio recording of it and not being there in the moment. Still, I found it to be worth listening as Turchi encouraged us to "get lost" when we want to create. We usually think of getting lost as something that happens to us when we are trying to get somewhere else. That makes getting lost something we wish wouldn't happen at all. But when we get lost in a new land inside our minds, we discover something new that we could not have seen before, at least not in the same way.

As I listened, I heard three ideas that captured much of the essence of Turchi's keynote. First was that we should strive to avoid preconception. This can be tough to do, because ultimately it means that we must work without knowing what is good or bad! The notions of good and bad are themselves preconceptions. They are valuable to scientists and engineers as they polish up a solution, but they often are impediments to discovering or creating a solution in the first place.

Second was the warning that a failure to get lost is a failure of imagination. Often, when we work deeply in an area for a while, we sometimes feel as if we can't see anything new and creative because we know and understand the landscape so well. We have become "experts", which isn't always as dandy a status as it may seem. It limits what we see. In such times, we need to step off the easy path and exercise our imaginations in a new way. What must I do in order to see something new?

This leads to the third theme I pulled from Turchi's talk: getting lost takes work and preparation. When we get stuck, we have to work to imagine our way out of the rut. For the creative person, though, it's about more about getting out of a rut. The creative person needs to get lost in a new place all the time, in order to see something new. For many of us, getting lost may seem like as something that just happens, but the person who wants to be lost has to prepare to start.

Turchi mentioned Robert Louis Stevenson as someone with a particular appreciation for "the happy accident that planning can produce". But artists are not the only folks who benefit from these happy accidents or who should work to produce the conditions in which they can occur. Scientific research operates on a similar plane. I am reminded again of Robert Root-Bernstein's ideas for actively engaging the unexpected. Writers can't leave getting lost to chance, and neither can scientists.

Turchi comes from the world of writing, not the world of science. Do his ideas apply to the computer scientist's form of writing, programming? I think so. A couple of years ago, I described a structured form of getting lost called air-drop programming, which adventurous programmers use to learn a legacy code base. One can use the same idea to learn a new framework or API, or even to learn a new programming language. Cut all ties to the familiar, jump right in, and see what you learn!

What about teaching? Yes. A colleague stopped by my office late last week to describe a great day of class in which he had covered almost none of what he had planned. A student had asked a question whose answer led to another, and then another, and pretty soon the class was deep in a discussion that was as valuable, or more, than the planned activities. My colleague couldn't have planned this unexpectedly good discussion, but his and the class's work put them in a position where it could happen. Of course, unexpected exploration takes time... When will they cover all the material of the course? I suspect the students will be just fine as they make adjustments downstream this semester.

What about running? Well, of course. The topic of air-drop programming came up during a conversation about a general tourist pattern for learning a new town. Running in a new town is a great way to learn the lay of the land. Sometimes I have to work not to remember landmarks along the way, so that I can see new things on my way back to the hotel. As I wrote after a glorious morning run at ChiliPLoP three years ago, sometimes you run to get from Point A to Point B; sometimes, you should just run. That applies to your hometown, too. I once read about an elite women's runner who recommended being dropped off far from your usual running routes and working your way back home through unfamiliar streets and terrain. I've done something like this myself, though not often enough, and it is a great way to revitalize my running whenever the trails start look like the same old same old.

It seems that getting lost is a universal pattern, which made it a perfect topic for an OOPSLA keynote talk.

... when Charlie Eppes invokes your research area on Numb3rs. In the episode I saw last Friday, the team used a recommender system, among other snazzy techie glitz, to track down a Robin Hood who was robbing from the dishonestly rich and giving to the poor through a collection of charities. A colleague of mine does work in recommender systems and collaborative filtering, so I thought of him immediately. His kind of work has entered the vernacular now.

I don't recall the Numb3rs crew ever referring to knowledge-based systems or task-specific architectures, which was my area in the old days. Nor do I remember any references to design patterns or to programming language topics, which is where I have spent my time in the last decade or so. Should I feel left out?

But Charlie and Amita did use the idea of steganography in an episode two years ago, to find a pornographic image hidden inside an ordinary image. I have given talks on steganography on campus occasionally in the last couple of years. The first time was at a conference on camouflage, and most recently I spoke to a graphic design class, earlier this month. (My next engagement is at UNI's Saturday Science Showcase, a public outreach lecture series my college runs in the spring.) So I feel like at least some of my intellectual work has been validated.

Coincidentally, I usually bill my talks on this topic as "Numb3rs Meets The Da Vinci Code: Information Masquerading as Art", and one of the demonstrations I do is to hide an image of Numb3rs guys in a digitized version of the Mona Lisa. The talk is a lot of fun for me, but I wonder if college kids these days pay much attention to network television, let alone da Vinci's art.

Lest you think that only we nth-tier researchers care to have our areas trumpeted in the pop world, even the great ones can draw such pleasure. Last spring, Grady Booch gave a keynote address at SIGCSE. As a part of his opening, he played for us a clip from a TV show that had brightened his day, because it mentioned, among other snazzy techie glitz, the Unified Modeling Language he had helped to create. Oh, and that video clip came from... Numb3rs!

My horoscope says so:

Thursday, January 24

Scorpio (October 24-November 22) -- You are smart enough to realize meeting force with force will only result in non-productive developments. To your credit, you will turn volatile matters around with wisdom, consideration, and gentleness.

Now, I may not really be smart enough, or wise enough, or even gentle enough. But on days like today it is good to hear such advice. Managing a team, a faculty, or a class involves a lot or relationships and a lot of personalities. Using wisdom, consideration, and gentleness is usually a more effective way to deal with unexpected conflicts than responding in kind or brute force.

Some days, my horoscope fits my situation perfectly. Today is one. But I promise not to turn to the zodiac for future blogging inspiration, unless it delivers a similarly general piece of advice.

One piece of good news from the past week: My permalinks should work now! Our college web server is once again behaving as it should, which means that http://www.cs.uni.edu/~wallingf/blog/ will not redirect to a http://cns2.uni.edu/ URL. This means that my permalinks, which are in the www.cs.uni.edu domain, will once again work. This makes me happy, and I hope that it makes it easier for folks to link directly to articles that they discuss in their own blogs. There may still be a problem with the category pages, but the sysadmins should have that fixed soon.

Now for that Bloglines issue... I haven't had much luck getting help from the Bloglines team, but I'll keep trying.

[Nothing new here for regular readers... This post implements an idea that I saw on Brian Marick's blog and liked: a table of contents for a set of conference posts coupled with cross-links as notes at the top of each entry. I have done a table of contents before, for OOPSLA 2005 -- though, sadly, not for 2004 or 2006 -- but I like the addition of the link back from entries to the index. This may help readers follow my entries, especially when they are out of order, and it may help me when I occasionally want to link back to the workshop as a unit.]

This set of entries records my experiences at the SECANT 2007 workshop November 17-18, hosted by the Purdue Department of Computer Science.

Primary entries:

• Workshop Intro: Teaching Science and Computing
  -- on building a community
• Workshop 1: Creating a Dialogue Between Science and CS
  -- How can we help scientists and CS folks work together?
• Workshop 2: Exception Gnomes, Garbage Collection Fairies, and Problems
  -- on a hodgepodge of sessions around the intersection of science ed and computing
• Workshop 3: The Next Generation
  -- what scientists are doing out in the world and how computer scientists are helping them
• Workshop 4: Programming Scientists
  -- Should scientists learn to program? And, if so, how?
• Workshop 5: Wrap-Up
  -- on how to cause change and disseminate results

Ancillary entries:

• A Program is an Idea
  -- going farther on why scientists, and everyone else, should learn to program

The next few items on the newsfeed will be these entries, updated with the "transcript" cross-link. [Done]

Now that things have wound down for the semester, I hope to do some mental clean-up and some CS. As much as I enjoyed the SECANT workshop last month (blogged in detail ending here), travel that late in a semester compresses the rest of the term into an uncomfortably small box. That said, going to conferences and workshops is essential:

Wherever you work, most of the smart people are somewhere else.

I saw that quote attributed to Bill Joy in an article by Tim Bray. Joy was speaking of decentralization and the web, but it applies to the pre-web network that makes up any scholarly discipline. Even with the web, it's good to get out of the tower every so often and participate in an old-fashioned conversation.

One part of the semester clean-up will be assessing the state of my department head backlog. Most days, I add more things to my to-do list than I am unable to cross off. Some of them are must-dos, details, and others are ideas, dreams. By the end of the semester, I have to be honest that many of the latter won't be done, soon if ever. I don't do a hard delete of most of these items; I just push them onto a "possibilities" list that can grow as large as it likes without affecting my mental hygiene.

I recently told my dean that, after two and a half years as head, I had almost come to peace with what I have taken to calling "time management by burying". He just smiled and said that the favorite part of his semester is doing just that, looking at his backlog and saying to himself, "Well, guess I'm not going to do that" as he deleted it from the list for good. Maybe I should be more ruthless myself. Or maybe that works better if you are a dean...

I've been following the story of the University of Michigan hiring West Virginia University's head football coach. Whatever one thinks of the situation -- and I think it brings shame to both Michigan and its new coach -- there was a very pragmatic piece of advice to be learned about managing people from one Pittsburgh Post-Gazette sports article about it. Says Bob Reynolds, former chief operating officer of Fidelity Investments:

I've been the COO of a 45,000-person company. When somebody's producing, you ask, 'What can I do for you to make your life better?' Not 'What can I do to make your life more miserable?'

That's a good thought for an academic department head to start each day with. And maybe a CS instructor, too.

I had to drive to Des Moines for a luncheon today. Four hours driving, round-trip, for a 1.25-hour lunch -- the things I do for my employer! The purpose of the trip was university outreach: I was asked to represent the university at a lunch meeting of the Greater Des Moines Committee, in place of our president and dean.

The luncheon was valuable for making connections to the movers and shakers in the capital city, and for talking to business leaders about computer science enrollments, math and science in the K-12 schools, and IT policy for the state. The lunch speaker, Ted Crosbie, the chief technology officer of Iowa, gave a good talk on economic development and the future of the state's technology efforts.

But was it all worth four hours on the road? Probably so, but I will give a firm Yes, for an unexpected reason.

A couple of minutes after I took my seat for lunch, former Iowa Governor Terry Branstad (1983-1999) sat down at our table. He struck up a nice conversation. Then, a couple of minutes later, former Iowa Governor Robert Ray (1969-1983) joined us. Very cool. I was impressed at how involved and informed these retired public officials remain in the affairs of the state, especially in economic development. The latter is, of course, something of great importance to my department and its students, as well as the university as a whole.

Then on the drive home, I saw a bald eagle soar majestically over a small riverbed. A thing of beauty.

On this and every day:

For the harvests of the Spirit, Thanks be to God;
For the good we all inherit, Thanks be to God;
For the wonders that astound us,
For the truths that will confound us,
Most of all that love has found us, Thanks be to God.

(Lyric by Fred Pratt Green, copyright 1970. Sung to a traditional Welsh melody.)

Among so many things, I'm thankful for the chance to write here and to have people read what I write.

Happy Thanksgiving.

[A transcript of the SECANT 2007 workshop: Table of Contents]

The last bit of the SECANT workshop focused on how to build a community at this intersection of CS and science. The group had a wide-ranging discussion which I won't try to report here. Most of it was pretty routine and would not be of interest to someone who didn't attend. But there were a couple of points that I'll comment on.

On how to cause change.     At one point the discussion turned philosophical, as folks considered more generally how one can create change in a larger community. Should the group try to convince other faculty of the value of these ideas first, and then involve them in the change? Should the group create great materials and courses first and then use them to convince other faculty? In my experience, these don't work all that well. You can attract a few people who are already predisposed to the idea, or who are open to change because they do not have their own ideas to drive into the future. But folks who are predisposed against the idea will remain so, and resist, and folks who are indifferent will be hard to move simply because of inertia. If it ain't broke, don't fix it.

Others expressed these misgivings. Ruth Chabay suggested that perhaps the best way to move the science community toward computational science is by producing students who can use computation effectively. Those students will use computation to solve problems. They will learn deeper. This will catch the eye of other instructors. As a result, these folks will see an opportunity to change how they teach, say, physics. We wouldn't have to push them to change; they would pull change in. Her analogy was to the use of desktop calculators in math, chemistry, and physics classes in the 1970s and 1980s. Such a guerilla approach to change might work, if one could create a computational science course good enough to change students and attractive enough to draw students to take it. This is no small order, but it is probably easier than trying to move a stodgy academic establishment with brute force.

On technology for dissemination.     Man, does the world change fast. Folks talked about Facebook and Twitter as the primary avenues for reaching students. Blogs and wikis were almost an afterthought. Among our students, e-mail is nearly dead, only 20 years or so after it began to enter the undergraduate mainstream. I get older faster than the calendar says because the world is changing faster than the days are passing.

Miscellaneous.     Purdue has a beautiful new computer science building, the sort of building that only a large, research school can have. What we might do with a building at an appropriate scale for our department! An extra treat for me was a chance to visit a student lounge in the building that is named for the parents of a net acquaintance of mine, after he and his extended family made a donation to the building fund. Very cool.

I might trade my department's physical space for Purdue CS's building, but I would not trade my campus for theirs. It's mostly buildings and pavement, with huge amounts of auto traffic in addition to the foot traffic. Our campus is smaller, greener, and prettier. Being large has its ups and its downs.

Thanks to a recommendation of the workshop's local organizer, I was able to enjoy some time running on campus. Within a few minutes I found my way to some trails that head out into more serene places. A nice way to close the two days.

All in all, the workshop was well worth my time. I'll share some of the ideas among my science colleagues at UNI and see what else we can do in our own department.

Earlier this week, I read The Geomblog's A day in the life..., in which Suresh listed what he did on Monday. Research did not appear on the list.

I felt immediate and intense empathy. On Monday, I had spent all morning on our college's Preview Day, on which high school students who are considering studying CS at my university visit campus with their parents. It is a major recruiting effort in our college. I spent the early morning preparing my discussion with them and the rest of the morning visiting with them. The afternoon was full of administrative details, computer labs and registration and prospective grad students. On Tuesday, when I read the blog entry, I had taught compilers -- an oasis of CS in the midst of my weeks -- and done more administration: graduate assistantships, advising, equipment purchases, and a backlog of correspondence. Precious little CS in two days, and no research or other scholarly activity.

Alas, that is all too typical. Attending an NSF workshop this week is a wonderful chance to think about computer science, its application in the sciences, and how to teach it. Not research, but computer science. I only wish I had a week or five after it ends to carry to fruition some of the ideas swirling around my mind! I will have an opportuniy to work more on some of these ideas when I return to the office, as a part of my department's curricular efforts, but that work will be spread over many weeks and months.

That is not the sort of intense, concentrated work that I and many other academics prefer to do. Academics are bred for their ability to focus on a single problem and work intensely on it for long periods of time. Then comes academic positions that can spread us quite then. An administrative position takes that to another level.

Today at the workshop, I felt a desire to bow down before an academic who understands all this and is ready to take matters into his own hands. Some folks were discussing the shortcomings of the current Mac OS X version of VPython, the installation of which requires X11, Xcode, and Fink. Bruce Sherwood is one of the folks in charge of VPython. He apologized for the state of the Mac port and explained that the team needs a Mac guru to build a native port. They are looking for one, but such folks are scarce. Never fear, though... If they can't find someone soon, Sherwood said,

I'm retiring so that I can work on this.

Now that is commitment to a project. We should all have as much moxie! What do you say, Suresh?

My apologies to the 130-odd of you who read this blog via Bloglines. A couple of you have alerted me to a technical issue with links disappearing from my posts when you read Knowing and Doing through the Bloglines interface. The problem is intermittent, which makes it frustrating for you all and harder for me to track down.

I've validated my RSS feed at http://feedvalidator.org and looked for some clues in the HTML source. No luck. At this point, I have asked the folks at Bloglines to see if they can find something in my feed that interacts badly with their software. I'll keep you posted.

Last Saturday morning, I opened a book at random, just to fill some time, and ended up writing a blog entry on electronic communities. It was as if the book were magic... I opened to a page, read a couple of sentences, and was launched on what seemed like the perfect path for that morning. That experience echoed one of the things Vonnegut himself has often said: there is something special about books.

This is one reason that I don't worry about getting dumber by reading books, because for me books have always served up magic.

I remember reading just that back in high school, in Richard Bach's Illusions:

I noticed something strange about the book. "The pages don't have numbers on them, Don."

"No," he said. "You just open it and whatever you need most is there."

"A magic book!"

These days, I often have just this experience on the web, as I read blogs and follow links off to unexpected places. An academic book or conference proceedings can do the same. Bach would have said, "But of course."

"No you can do it with any book. You can do it with an old newspaper, if you read carefully enough. Haven't you done that, hold some problem in your mind, then open any book handy and see what it tells you?"

I do that sometimes, but I'm just as likely to catch a little magic when my mind is fallow, and I grab a paper of one of my many stacks for a lunch jaunt. Holding a particular problem in my mind sometimes puts too much pressure on whatever might happen.

Indeed, this comes back to the theme of the article I wrote on Saturday morning. On one hand there are traditional media and traditional communities, and on the other are newfangled electronic media and electronic communities. The traditional experiences often seem to hold some special magic for us. But the magic is not in any particular technology; it is in the intersection between ideas out there and our inner lives.

When I feel something special in the asynchronicity of a book's magic, and think that the predetermination of an RSS feed makes it less spontaneous, that just reflects my experience, maybe my lack of imagination. If I look back honestly, I know that I have stumbled across old papers and old blog posts and old web pages that served up magic to me in much the same way that books have done. And, like electronic communities, the digital world of information creates new possibilities for us. A book can be magic for me only if I have a copy handy. On the web, every article is just a click a way. That's a powerful new sort of magic.

Over on one of the mailing lists I browse -- maverick software development -- there has been a lot of talk about how a lack of trust is one of the primary dysfunctions of teams. The discussion started as a discussion of Patrick Lencioni's The Five Dysfunctions of a Team but has taken on its own life based on the experiences of the members of the list.

One writer there made the bold claim that all team dysfunctions are rooted in a lack of trust. Others, such as fear of conflict and lack of commitment to shared goals, grow solely from a lack of trust among team members and leaders. This is, in fact, what Lencioni claims in his book, that a lack of trust creates an environment in which people fear conflict, which ensures a lack of commitment and ultimately an avoidance of accountability, ending in an inattention to the results produced by the team.

The writer who made this claim asked list members for specific counterexamples. I don't know if I can do that, but I will say that it's amazing what a lack of confidence can do to an individual's outlook and performance, and ultimately on his or her ability to contribute positively as a team member.

When a person lacks confidence in his ability, he will be inclined to interpret every contingent signal in a different way than it was intended. This interpretation is often extreme, and very often wrong. This creates an impediment to performance and to interaction.

I see it in students all the time. A lack of confidence makes it hard to learn! If I don't trust what I know or can do, then every new idea looks scary. How can I understand this if I don't understand the more fundamental material? I don't want to ask this question, because the teacher, or my classmates, will see how little I know. There's no sense in trying this; I'll just fail.

This is, I think a problem in CS classes between female and male students. Male students seem more likely than females to bluff their way through a course, pretending they understand something more deeply than they do. This gives everyone a distorted image of the overall understanding of the class, and leaves many female students thinking that they are alone in not "getting it". One of the best benefits of teaching a CS class via discussion rather than lecture is that over time the bluffers are eventually outed by the facts. I still recall one of our female students telling me in the middle of one of my courses taught in this way that she finally saw that no one else had any better grasp on the material than she did and that, all things considered, she was doing pretty well. Yes!

I see the effects of lack of confidence in my faculty colleagues, too. This usually shows up in a narrow context, where the person doesn't know a particular area of computing very well, or lacks experience in a certain forum, and as a result shies away from interacting in venues that rely on this topic. I also see this spill over into other interactions, where a lack of confidence in one area sets the tone for fear of conflict (which might expose an ignorance) and disengagement from the team.

I see it in myself, as instructor on some occasions and as a faculty member on others. Whenever possible I use a lack of confidence in my understanding of a topic as a spur to learn more and get better. But in the rush of days this ideal outlook often falls victim to rapidly receding minutes.

A personal lack of confidence has been most salient to me in my role as a department head. This was a position for which I had received no direct training, and grousing about the performance of other heads offers only the flimsiest foundation for doing a better job. I've been sensitized to nearly every interaction I have. Was that a slight, or standard operating procedure? Should I worry that my colleague is displeased with something I've done, or was that just healthy feedback? Am I doing a good enough job, or are the faculty simply tolerating me? As in so many other contexts, these thoughts snowball until they are large enough to blot everything else out of one's sight.

The claimant on the mailing list might say that trust is the real issue here. If the student trusts his teacher, or the faculty member trusts his teammates, or the department head trusts his faculty, either they would not lack confidence or would not let it affect their reactions. But that is precisely the point: they are reactions, from deep within. I think we feel our lack of confidence prior to processing the emotion and acting on trust. Lack of confidence is probably not more fundamental than lack of trust, but I think they are often orthogonal to one another.

How does one get over a lack of confidence? The simplest way is to learn what we need to know, to improve our skills. In the mean time, a positive attitude -- perhaps enabled by a sense of trust in our teammates and situation -- can do wonders. Institutionally, we can have, or work to get, support from above. A faculty member who trusts that she has room to grow in the presence of her colleagues and head, or a new department who trusts that he has room to grow in the presence of his dean, will be able to survive a lack of confidence while in the process of learning. I've seen new deans and heads cultivate that sort of trust by acting cautiously at the outset of their tenure, so as not to lose trust before the relationship is on firm ground.

In the context of software development, the set of tasks for which someone is responsible is often more crisply delineated than the set of tasks for a student or manager. In one way, that is good news. If your lack of confidence stems from not knowing how Spring or continuation passing style works, you can learn it! But it's not too simple, as there are time constraints and team relationships to navigate along the way.

Ultimately, a mindset of detachment is perhaps the best tool a person who lacks confidence can have. Unfortunately, I do not think that detachment and lack of confidence are as common a package as we might hope. Fortunately, one can cultivate a sense of detachment over time, which makes dealing with recurring doubts about one's capabilities easier to manage over time.

If only it were as easy to do these things as it is to say them!

I volunteered to help with a local 5K/10K race this morning. When I arrived at my spot along the course, I had half an hour to fill before the race began, and 45 minutes or so before the first runners would reach me. At first I considered taking a short nap but feared I'd sleep too long. Not much help to the runners in that! So I picked up Kurt Vonnegut's A Man Without a Country, which was in my front seat on its way back to the library. (I wrote a recent article motivated by something else I read in this last book of Vonnegut's.)

I opened the book to Page 61, and my eyes fell immediately to:

Electronic communities build nothing. You end up with nothing. We are dancing animals.

This passage follows a wonderful story about how Kurt mails his manuscripts, daily coming into contact with international voices and a flamboyant postal employee on whom he has a crush. I've heard this sentiment before, in many different contexts and from many different people, but fundamentally I disagree with the claim. Let me tell you about two stories of this sort that stick in my mind, and my reactions at the time.

A decade or so ago, the famed philosopher and AI critic Hubert Dreyfus came to our campus to deliver a lecture as part of an endowed lecture series in the humanities. Had I been blogging at that time, I surely would have written a long review of this talk! Instead, all I have a notebook on my bookshelf full of pages and pages of notes. (Perhaps one of these days...) Dreyfus claimed that the Internet was leading to a disintegration of society by creating barriers to people connecting in the real world. Electronic communication was supplanting face-to-face communication but giving us only an illusion of a real connection; in fact, we were isolating ourselves from one another.

In the question-and-answer session that followed, I offered a counterargument. Back in the mid-1980s I became quite involved in several Usenet newsgroups, both for research and entertainment. In the basketball and football newsgroups, I found intelligent, informed, well-rounded people with who to discuss sports at a deeper level than I could with anyone in my local physical world. These groups became an important part of my day. But as the number of people with Internet access exploded, especially on college campuses, the signal-to-noise ratio in the newsgroups fell precipitously. Eventually, a core group of the old posters moved much of discussion off-group to a private mailing list, and ultimately I was invited to join them.

This mailing list continues to this day, taking on and losing members as lives change and opportunities arise. We still discuss sports and politics, pop culture and world affairs. It is a community as real to me as most others, and I consider some of the folks there to be good friends whom I'm lucky to have come to know. Members of the basketball group get together in person annually for the first two rounds of the NCAA tournament, and wherever we travel for business or pleasure we are likely to be in the neighborhood of a friend we can join for a meal and a little face-to-face communication. Like any real community, there are folks in the group whom I like a lot and others with whom I've made little or no personal connection. On-line we have good moments and disagreements and occasional hurt feelings, like any other community of people.

The second story I remember most is from Vonnegut himself, when he, too, visited my campus back when. At one of the sessions I attended, someone asked him about the fate of books in the Digital Age. Vonnegut was certain that books would continue on in much their current form, because there was something special about the feel of a book in one's hands, the touch of paper on the skin, the smell of the print and binding. Even then I recall disagreeing with this -- not because I don't also feel that something special in the feel of a book in my hands or the touch of the paper on my skin. A book is an artifact of history, an invention of technology. Technology changes, and no matter how personally we experience a particular technology's outward appearance, it is more likely to be different in a few years than to be the same.

My Usenet newsgroup story seems to contradict Dreyfus's thesis, but he held that, because we took it upon ourselves to meet in person, my story actually supported it. To me that seemed a too convenient way for him to dismiss the key point: our sports list is essentially an electronic community, one whose primary existence is virtual. Were the Internet to disappear tomorrow, some of the personal connections we've made would live on, but the community would die.

And keep in mind that I am old guy... Today's youth grow up in a very different world of technology than we did. One of the specific sessions I regret missing by missing OOPSLA was the keynote by Jim Purbrick and Mark Lentczner on Second Life, a new sort of virtual world that may well revolutionize the idea of electronic community not only for personal interaction but for professional, corporate, and economic interaction as well. As an example, OOPSLA itself had an island in Second Life as a way to promote interaction among attendees before and during the conference.

The trend in the world these days is toward more electronic interaction, not less, and new kinds that support wider channels of communication and richer texture in the interchange. There are risks in this trend, to be sure. Who among us hasn't heard the already classic joke about the guy who needs a first life before he can have a Second Life? But I think that this trend is just another step in the evolution of human community. We'll find ways to minimize the risks while maximizing the benefits. The next generation will be better prepared for this task than old fogies like me.

All that said, I am sympathetic to the sentiment that Vonnegut expressed in the passage quoted above, because I think underlying the sentiment is the core of a truth about being human. He expresses his take on that truth in the book, too, for as I turned the page of the book I read:

We are dancing animals. How beautiful it is to get up and go out and do something. We are here on Earth to fart around. Don't let anybody tell you any different.

I know this beauty, and I'm sure you do. We are physical beings. The ability and desire to make and share ideas distinguish us from the rest of the world, but still we are dancing animals. There seems in us an innate need to do, not just think, to move and see and touch and smell and hear. Perhaps this innate trait is why I love to run.

But I am also aware that some folks can't run, or for whatever reason cannot sense our physical world in the same way. Yet many who can't still try to go out and do. At my marathon last weekend, I saw men who had lost use of their legs -- or lost their legs altogether -- making their way over 26.2 tough miles in wheelchairs. The long uphill stretches at the beginning of the course made their success seem impossible, because every time they released their wheels to grab for the next pull forward they lost a little ground. Yet they persevered. These runners' desire to achieve in the face of challenge made my own difficulties seem small.

I suspect that these runners' desire to complete the marathon had as much to do with a sense of loss as with their innate nature as physical beings. And I think that this accounts for Vonnegut's and others' sentiment about the insufficiency of electronic communities: a sense of loss as they watch the world around evolve quickly into something very different from the world in which they grew.

Living in the physical world is clearly an important part of being human. But it seems to be neither necessary nor sufficient as a condition.

Like Vonnegut, I grew up in a world of books. To me, there is still something special about the feel of a book in my hands, the touch of paper on my skin, the smell of the print and binding of a new book the first time I open it. But these are not necessary parts of the world; they are artifacts of history. The sensual feel of a book will change, and humanity will survive, perhaps none they worse for it.

I can't say that face-to-face communities are merely an artifact of history, soon to pass, but I see no reason to believe that the electronic communities we build now -- we do build them, and they so seem to last, at least on the short time scale we have for judging them -- cannot augment our face-to-face communities in valuable ways. I think that they will allow us to create forms of community that were not available to us before, and thus enrich human experience, not diminish it. While we are indeed dancing animals, as Vonnegut describes us, we are also playing animals and creative animals and thinking animals. And, at our core, we are connection-making animals, between ideas and between people. Anything that helps us to make more, different, and better connections has a good chance of surviving in some form as we move into the future. Whether dinosaurs like Vonnegut or I can survive there, I don't know!

Some days I read a paper or two and feel like I've lost ground. I just have more to read, think, and do. Of course, this phenomenon is universal... As Design Observer tells us, reading makes us more ignorant:

According to the Mexican critic Gabriel Zaid, writing in "So Many Books: Reading and Publishing in an Age of Abundance", ... "If a person read a book a day, he would be neglecting to read 4,000 others... and his ignorance would grow 4,000 times faster than his knowledge."

Don't read a book today! Now there is a slogan modern man can get behind. It seems that a few college students have already signed on.

My hope for most days is just the opposite. Here is a nice graphic slogan for this hope, courtesy of Brian Marick:

But it's hard to feel that way some days. The universe of knowing and doing is large. The best antidote to Sisyphean despair is to set a few measurable goals that one can reach with a reasonable short-term effort. Each step can give a bit of satisfaction, and -- if you take enough such steps -- you can end up someplace new. A lot like writing code.

Today I wrote a program, just for fun. I wrote a solution to the classic WordLadder game, which is a common nifty assignment used in the introductory Data Structures course. I had never assigned it in one of my courses and had never had any other reason to solve it. But my daughter came home yesterday with a math assignment that included a few of these problems, such as converting "heart" to "spade", and in the course of talking with her I ended up doing a few of the WordLadder problems on my own. I'm a hopeless puzzle junkie.

Some days, an almost irrational desire to write a program comes over me, and last night's fun made me think, "I wonder how I might do this in code?" So I used a few spare minutes throughout today to implement one of my ideas from last night -- a simple breadth-first search that finds all of the shortest solutions in a particular dictionary.

A few of those spare minutes came at the public library, while the same daughter was participating in a writers' workshop for youth. As I listened to their discussion of a couple of poems written by kids in the workshop in the background, I thought to myself, "I'm writing here, too." But then it occurred to me that the kids in the workshop wouldn't call what I was doing "writing". Nor would their workshop leader or most people that we call "writers". Nor would most computer scientists, not without the rest of the phrase: "writing a program".

Granted, I wasn't writing a poem. But I was exploring an idea that had come into my mind, one that drove forward. I wasn't sure what sort of program I would end up, and arrived at the answer only after having gone down a couple of expected paths and found them wanting. My stanzas, er, subprocedures, developed over time. One grew and shrank, changed name, and ultimately became much simpler and clearer than what I had in mind when I started.

I was telling a story as much as I was solving a problem. When I finished, I had a program that communicates to my daughter an idea I described only sketchily last night. The names of my variables and procedures tell the story, even without looking at too much of their detail. I was writing as a way to think, to find out what I really thought last night.

Today I wrote a program, and it was fun.

There is a great scene toward the end of one of my favorite movies, An Officer and a Gentleman. The self-centered and childlike protagonist, Zach Mayo, has been broken down by Drill Instructor Foley. He is now maturing under the Foley's tough hand. The basic training cohort is running the obstacle course for its last time. Mayo is en route to a course record, and his classmates are urging him on. But as his passes one of his classmates on the course, he suddenly stops. Casey Seeger has been struggling with wall for the movie, and it looks like she still isn't going to make it. But if she doesn't, she won't graduate. Mayo sets aside his record and stands with Seeger, cheering her and coaching her over the wall. Ultimately, she makes it over -- barely -- and the whole class gathers to cheer as Mayo and Seeger finish the run together. This is one of the triumphant scenes of the film.

I thought of this scene while running mile repeats on the track this morning. Three young women in the ROTC program were on the track, with two helping the third run sprints. The two ran alongside their friend, coaxing her and helping her continue when she clearly wanted to stop. If I recall correctly from my sister's time in ROTC, morning PT (physical training) is a big challenge for many student candidates and, as in An Officer and a Gentleman, they must meet certain fitness thresholds in order to proceed with the program -- even if they are in non-combat roles, such as nurses.

It was refreshing to see that sort of teamwork, and friendship, among students on the track.

It is great when this happens in one our classes. But when it does, it is generally an informal process that grows among students who were already friends when they came to class. It is not a part of our school culture, especially in computer science.

Some places, it is part of the culture. A professor here recently related a story from his time teaching in Taiwan. In his courses there, the students in the class identified a leader, and then they worked together to make sure that everyone in the class succeeded. This was something that students expected of themselves, not something the faculty required.

I have seen this sort of collectivism imposed from above by CS professors, particularly in project courses that require teamwork. In my experience, it rarely works well when foisted on students. The better students resent having their grade tied to a weaker student's, or a lazier one's. (Hey, it's all about the grade, right?) The weaker students resent being made someone else's burden. Maybe this is a symptom of the Rugged Individualism that defines the West, but working collectively is generally just not part of our culture.

And I understand how the students feel. When I found myself in situations like this as a student, I played along, because I did what my instructors asked me to do. And I could be helpful. But I don't think it ever felt natural to me; it was an external requirement.

Recently I found myself discussing pair programming in CS1 with a former student who now teaches for us. He is considering pairing students in the lab portion of his non-majors course. Even after a decade, he remembers (fondly, I think) working with a different student each week in my CS1 lab. But the lab constituted only a quarter of the course grade, and the lab exercises did not require long-term commitment to helping the weakest members of the class succeed. Even still, I had students express dissatisfaction at "wasting their time".

This is one of the things that I like about the agile software methods: it promotes a culture of unity and of teamwork. Pair programming is one practice that supports this culture, but so are collective ownership, continuous integration, and coding standard. Some students and programmers, including some of the best, balk at being forced into "team". Whatever the psychological, social, and political issues, and whatever my personal preferences as a programmer, there seems something attractive about a team working together to get better, both as a team and as individuals.

I wish the young women I saw this morning well. I hope they succeed, as a team and as individuals. They can make it over the wall.

As you seek the three great virtues of a programmer, you seek to cultivate...

... the kind of laziness that makes you want to minimize future effort but investing effort today, to maximize your productivity and performance over the long haul, not the kind that leads you to avoid essential work or makes you want to cut corners.

... the kind of impatience that encourages you to work harder, not the kind of impatience that steals your spirit when you hit a wall or makes you want to cut corners.

... the kind of hubris that makes you think that you can do it, to trust yourself, not the kind of hubris that makes you think you don't have to listen to the problem, your code, or other people -- or the kind that makes you want to cut corners.

The last week or so I've been trying to steal a few minutes each day to clean up the closet in my home work area. One of the big jobs has been to get rid of several years of journals and proceedings that built up from 1998 to 2002, when it seems I had time only to skim my incoming periodicals.

I seem genetically unable to simply through these into a recycling bin; instead, I sit on the floor and thumb through each, looking at least at the table of contents to see if there is anything I still want to read. Most of the day-to-day concerns in 2000 are of no particular interest now. But I do like to look at the letters to the editor in Communications of the ACM, IEEE Computer, and IEEE Spectrum, and some of the standing columns in SIGPLAN Notices, especially on Forth and on parsing. Out of every ten periodicals or so, I would guess I have saved a single paper or article for later reading.

One of the unexpected joys has been stumbling upon all of the IEEE Spectrum issues. It's one of the few general engineering generals I've ever received, and besides it has the bimonthly Reflections column by Robert Lucky, which I rediscovered accidentally earlier this month. I had forgotten in the off-months of Reflections, Spectrum runs a column called Technically Speaking, which I also enjoy quite a bit. According to its by-line, this column is "a commentary on technical culture and the use and misuse of technical language". I love words and learning about their origin and evolution, and this column used to feed my habit.

Most months, Technically Speaking includes a sidebar called "Worth repeating", which presents a quote of interest. Here are a couple that struck me as I've gone through my old stash.

From April 2000:

Engineering, like poetry, is an attempt to approach perfection. And engineers, like poets, are seldom completely satisfied with their creations.... However, while poets can go back to a particular poem hundreds of times between its first publication and its final version in their collected works, engineers can seldom make major revision in a completed structure. But an engineer can certainly learn from his mistakes.

This is from Henry Petroski, in To Engineer is Human. The process of discovery in which an engineer creates a new something is similar to the poet's process of discovery. Both lead to a first version by way of tinkering and revision. As Petroski notes, though, when engineers who build bridges and other singular structures publish their first version, it is their last version. But I think that smaller products which are mass produced often can be improved over time, in new versions. And software is different... Not only can we grow a product through a conscious process of refactoring, revision, and rewriting from scratch, but after we publish Version 1.0 we can continue to evolve the product behind its interface -- even while it is alive, servicing users. Software is a new sort of medium, whose malleability makes cleaving too closely to the engineering mindset misleading. (Of course, software developers should still learn from their mistakes!)

From June 2000:

You cannot have good science without having good science fans. Today science fans are people who are only interested in the results of science. They are not interested in a good play in science as a football fan is interested in a good play in football. We are not going to be able to have an excellent scientific effort unless the man in the street appreciates science.

This is reminiscent of an ongoing theme in this blog and in the larger computer science community. It continues to be a theme in all of science as well. How do we reform -- re-form -- our education system so that most kids at least appreciate what science is and means? Setting our goal as high as creating fans as into science as into football or NASCAR would be ambitious indeed!

Oh, and don't think that this ongoing theme in the computer science and general scientific world is a new one. The quote above is from Edward Teller, taken off the dust jacket of a book named Rays: Visible and Invisible, published in 1958. The more things change, the more they stay the same. Perhaps it should comfort us that the problem we face is at least half a century old. We shouldn't feel guilty that we cannot solve it over night.

And finally, from August 2000:

To the outsider, science often seems to be a frightful jumble of facts with very little that looks human and inspiring about it. To the working scientist, it is so full of interest and so fascinating that he can only pity the layman.

I think the key here is make moire people insiders. This is what Alan Kay urges us to do -- he's been saying this for thirty years. The best way to share the thrill is to help people to do what we do, not (just) tell them stories.

I recently mentioned again Seth Godin's All Marketers are Liars in the context of teachers as liars. One last mention -- this time, for researchers and students.

As I read pages 29 and 30 of the book, I was struck by how much Godin's advice for marketers matches my experience as a researcher, first as a graduate student, then as a young faculty member, and now as a grizzled veteran. Consider:

There are only two things that separate success from failure in most organizations today:

1. Invent stuff worth talking about.
2. Tell stories about what you've invented.

That is the life of the academic researcher: invent cool stuff, and talk about the inventions. Some of my best professors were people who invented cool stuff and loved to talk about their inventions. They relished being in the lab, creating, and then crafting a story that shared their excitement. As a student, undergrad and grad alike, I was drawn to these profs, even when they worked in areas that didn't interest me much. When they did -- wow.

Many people get into research because we want to do #1, and #2 is just part of the deal. Whether the young researcher wants to or not, telling the stories is essential. It is how we spread our ideas and get the feedback that helps us to improve them. But on a more mercenary level it's also how we get folks interested in offering us tenure-track positions, and then offering us tenure.

Over the course of my career, I have come to realize how many people go into research because they want to do #2. As strange as it might sound, Getting a Ph.D. is one of the more attractive routes to becoming a professional story-teller, because it is the de facto credential for teaching at universities. Sometimes these folks continue to invent cool stuff to talk about. But some ultimately fall away from the research game. They want to tell stories, but without the external pressure to do #1. Maybe they lose the drive to invent, or never really had it in the first place. These folks often become great teachers, too, whether as instructors at research schools or as faculty at so-called "teaching universities". Many of those folks still have a passion for something like #1, but it tends toward learning about the new stuff that others create, synthesizing it, and preparing it for a wider audience. Then they tell the stories to their students and to the general public.

As I've written before, CS needs its own popular story teller, working outside the classroom, to share the thrill... I don't think that has to be an active researcher -- think about the remarkable effect that Martin Gardner had on the world by sharing real math with us in ways that made us want to do mathematics -- and even computer science! But having someone who continues to invent be that person would work just fine. Thank you, Mr. Feynman.

So, to my grad students and to graduate students everywhere, this is my advice to you: Invent stuff worth talking about, and then tell stories about what you've invented.

But this advice is not just for graduate students. Consider this passage from Godin, which I also endorse wholeheartedly:

On a personal level, your resume should be about inventing remarkable things and telling stories that register--not about how good you are at meeting specs. Organizations that are going to be around tomorrow will be those that stop spending all their time dealing with the day-to-day crises of shipping stuff out the door or reacting to emergencies. Instead the new way of marketing will separate winners from losers.

This is where the excitement and future of computer science in industry lie, too. Students who can (only) meet specs are plentiful and not always all that valuable. The real value comes in creating and integrating ideas. This is advice that I've been sharing with entrepreneurially-minded students for a while, and I think as time goes by it will apply to more and more students. Paul Graham has spent a lot of time spreading this message, in articles such as What You'll Wish You'd Known, and I've written about Graham's message here as well. The future belongs to people who are asking questions, not people who can deliver answers to other peoples' questions.

So, this advice is not just for students. It is for everyone.

I recently realized something.

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

Movies show us these images, too. So peaceful.

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

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

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

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

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

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

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

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

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

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

Sponsored outlets in the walkways of the concourses:

and

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

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

My last post looked at the relationship between honesty and blocking, motivated by a recent thread on the XP discussion list. In another thread, I encountered Dale Emery's message on The Prime Directive, and that got me to thinking about being honest with myself about my own behavior, and how to get better.

If you read much in the agile world, you'll run across the phrase "Prime Directive" a lot. I'm not a Trekkie, though I have enjoyed the several movies and TV series, but the first thing I think of when I hear the phrase is James T. Kirk. That's not what the agile folks are talking about... even if that directive raises interesting questions for a software person introducing agile methods to an organization!

If you google "prime directive agile", the first link is to Bob Martin's The Prime Directive of Agile Development, which is: Never be blocked. This is an ironic choice of words, given what I discussed in my previous post, but Martin is using an analogy from billiards, not football: An agile developer "makes sure that the shot he is taking sets up the next shot he expects to take.... A good agile developer never takes a step that stops his progress, or the progress of others." This is a useful notion, I think, but again not what most agilists mean when they speak of the Prime Directive.

They are referring instead to Norm Kerth's use of the phrase in the realm of project retrospectives, in which teams learn from the results of a recently-completed project in order to become a better team for future projects. Here is the Prime Directive for retrospectives, according to Norm:

The prime directive says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.

This directive creates an environment in which people can examine past actions and results without fear of blame or reprisal. Instead the whole team can find ways to improve. When we look back at behavior and results in this context, we can be honest -- with our teammates and with ourselves. It's hard to improve oneself without facing the brutal facts that define our world and our person.

Emery's article focuses on the power of the phrase "given what they knew at the time". He does not view it as a built-in excuse -- well, I didn't know any better, so... -- rather as a challenge to identify and adjust the givens that limit us.

I apply The Prime Directive to my personal work by saying, "I did the best I could, given..." then fill in the givens. Then I set to work removing or relaxing the limiting conditions so that I perform better in the future. Usually, the most important conditions are the conditions within me, the conditions that I created.... If I created those conditions (and I did), then they are the conditions I can most directly improve.

Well said. Being honest with myself isn't easy, nor is following through on what I learn when I am. I take this as a personal challenge for the upcoming year.

(By the way, I strongly recommend Norm Kerth's book on retrospectives, as well as his pattern language on the transition from software analysis to design, Caterpillar's Fate. Norm is an engaging speaker and doer who celebrates the human element in whatever he touches. I reported on a talk he gave at PLoP 2004 on myth and patterns back in the early days of this blog.)

I recently wrote about a long-running thread on the XP discussion list about defining 'agile'. Another theme I've noticed across several threads is honesty. This entry and the one that follows look at two facets of the theme.

In one thread that seems to be dying down, the list has discussed the ethics of "blocking", a term that Scott Ambler borrowed from (American) football to describe teams that create the facade of following the official software development methodology while behind the scenes doing what they think is best to deliver the software. Scott wrote about this behavior, in which some members of the team protect the agile process by Running Interference for the rest of the team, in a 2003 Software Development article.

Is it right to do this? As developers, do we want to live our lives doing one thing and saying that we do another? I'm leery of any prescription that requires me to lie, yet I see shades of gray here. I don't think that my employer or our client are better served by actually following a process that is likely to fail to deliver the software as promised. Or, if my team is capable of delivering the software reasonably using the official methodology, then why do I need to lie in order to use an agile process? For me, programming in an agile way is a lot more fun, so there is that, but then maybe I need to find a place that will let me do that -- or start my own.

As I mentioned last time, I have not been able to follow the list discussion 100%, and I can't recall if Kent Beck ever chimed in. But I can imagine what he might say, given the substance and tone of his postings the last few years. If you have to lie -- even if we give it an innocuous name like "blocking"; even if we view it as a last resort -- then something is wrong, and you should think long and hard about how to make it right. Agile developers value people over processes, and honesty is one way we demonstrate that we value people.

George Dinwiddie has a blog entry that considered a more pragmatic potential problem with blocking. We may be getting the job done in the short term, but blocking is shortsighted and may hurt the agile cause in the long run. If we give the appearance of succeeding via the official route, our employer and customer are likely to conclude that the official route is a good one -- and that will make it even harder to introduce agile practices into the workplace. There is a practical value in telling the truth, even it requires us to take small steps. After all, agile developers ought to appreciate the power of small steps.

... at the end of a long day.

1. I must be an old hand at blogging now. I let Knowing and Doing's third anniversary pass without comment. And I let my