Knowing and Doing

In my last post, I commented on academic searches. One of the articles I linked to gives some pretty good advice to prospective faculty applying for positions at smaller schools. They aren't fallback positions; they are different kinds of positions altogether. In the spirit of that post, I thought I'd share some of my recent experiences with other kinds of academic search.

This year, I am involved in a couple of high-profile searches on my campus, both of which matter very much to the faculty in my department. The first is for the chief sysadmin in the College of Natural Sciences, and the second is for the Assistant Vice President of information technology for the university. Both matter to us for the same reasons, though in different doses. In this post, I'll talk a bit about the sysadmin search.

Being a medium-sized "teaching university", we do not maintain and manage most of the basic computational resources that we use on a day-to-day basis. In the early years, before the rest of the college and university were deeply into technology, we did. But as our needs grew, and as other departments came to need computer labs and e-mail and the web, the college took on more and more of the systems burden. These days, the college sysadmin team implements and supports the network and server infrastructure for the college, manages the general college labs that our students use, and supports CS faculty labs and computer equipment. Not having the research money to maintain all of our department resources, this has worked out well enough for the last decade or so, with only occasional control issues arising. (One current one involves our web server, which for the last few weeks has been rewriting URLs in such a way as to break my blog permalinks.)

So, the college's lead sysadmin has a challenging job to do. There are a lot of technical tasks to do, plus managing student staff and providing user support. The diversity of issues that arise in the college is yet another challenge, ranging from a CS department, a math department, and industrial technology department, and the traditional natural sciences. In some ways, CS demands less personal support from the college, but we do have specific technical needs, sometimes outliers from the rest of the crowd, that we rely heavily on.

I'm chairing the college sysadmin search. In the process, I've come to appreciate just how hard it is to find candidates with sufficient technical skills and experience, sufficient "people" skills to work with a diverse audience of users, and sufficient managerial experience. Add to that a salary that is almost certainly lower than market value in private industry, and the task is even tougher. Even with these challenges, we have a promising pool of finalists and hope to begin on-campus interviews soon.

Here are some things that I've learned in the last few years and am trying to put into practice for this search:

• Technical skills matter. Period. You can't hire a sysadmin with marginal or insufficient skills and hope that they can grow into the job. technology changes so fast that most such folks never have the chance to catch up. They just fall farther and farther behind. Strong Unix and Windows background; experience setting up and configuring servers; broad experience with software -- all are essential. Don't settle for less lightly.
• Communication skills matter. A college-level sysadmin must be able to work with advanced and novice users alike, train students, and mentor full-time assistants. They also have to be able to explain technical choices and trends to department heads and deans, so that these administrators can make informed decisions about equipment and budgets. This latter is more important than many folks realize. Being a sysadmin at this level isn't just about hacking Ruby scripts to automate mechanical tasks; it also contains an element of helping others set vision.
• But do not emphasize communication skills to the detriment of technical skills. Of course, you can't emphasize technical skills to the detriment of communication skills either, but at my university and in our current environment, favoring tech skills to the expense of communication skills just hasn't been a problem. Folks are more inclined to go with someone who has people skills and is agreeable, even if they lack the skills necessary to do the job well. Don't do it. You'll always pay in the long run.
• On the search process itself: Fairness matters. Once you have published a job description, stick to it. It can be really tempting to say "I like this candidate's application..." and then start looking away from the ways in which the candidate falls short of the requirements and preferences that you had defined for the position at the outset of the search. This is a sure way to let your hidden biases get in the way of hiring the right candidate. The job description is your specification. If it is well thought out, you're almost certainly better off letting it guide the committee's actions.

  But I think it's also wrong to skirt the job description for another reason: It's unfair to other candidates who were honest about not meeting the requirements of the position and so didn't apply at all. If you are willing to consider folks in your pool who do not meet the specs, then you might really want to consider some of those who self-selected out of the pool through a sense of honor. And then there is the practical problem of having to relax the requirements fairly for all of the applicants in the pool, not just the one who caught your attention for some other reason.

  Maybe I'm too strict on this matter, but this sort of fairness is a sticky point for me. I try to manage my classroom similarly. If I feel a need to repeatedly relax a particular rule, then I probably need to change the rule, not relax it. Otherwise, exceptions tend to favor that certain group of students who are bold or needy enough to ask for exceptions, at the expense of the students who live by the rules quietly. (Can you guess which sort of student I most likely was?)

• Leadership matters. Once a sysadmin can put ship into seaworthy condition and have things running as they should, it's awfully nice to have someone in place who can think bigger thoughts and help guide the department or college. This isn't crucial, as faculty and other administrators are already charged with this task, but why waste the expertise that your sysadmin brings to the table, especially if they are inclined to help lead? Allowing them to do so helps the college and lets the sysadmin grow professionally.

We'll see how successful the college is at finding the right sort of person, with what bit of influence I have been able to exert.

Physics blogger Chad Orzel has written a couple of articles on the process of searching for new faculty, including his recent tips for applicants to schools like his. I haven't been part of a CS faculty search in a couple of years, after what seemed an interminable decade of trying and failing to feel an open slot or two. Our last two searches resulted in three hires, and we couldn't be much happier with the results. Our department is much better now than it was before.

I attribute our success as much to good fortune as to any particular actions we took. When I first became involved in job searches, I thought that a good search committee could reliably produce a good result. Write the correct job description, do the right sort of applicant screening and reference checking, and interview the finalists in the correct way, and out would pop the Ideal Candidate. After years of trying to do the job better, I came to understand how naive I had been. The process of searching for and hiring a member of the faculty is inherently risky, and the best one can do is hope to hire a good person while avoiding any major disasters. It's much easier to watch for the red flags that indicate a higher-than-usual level of risk than it is to recognize the signals that ensure a winner, but even on that side of the equation the committee must have the the patience it needs not to rush ahead in the presence of red flags.

Faculty searches are tougher than most, because the outcomes on which success will be measured are forecasts based on a small set of data points from a world that is not all that representative of the world in which new faculty will operate. We do our best and then act on faith in a person. Sometimes we just guess wrong. When things don't turn out right, both the new faculty member and the hiring department have suffered a loss. The split may be amicable, but neither party is better as a result.

For some staff positions, I think a good search committee can deliver a good result with a much higher probability, if only because the parameters of the position are easier to delineate and evaluate. Besides, there usually isn't the messy specter of a tenure decision complicating most such hires. But there's still an element of risk involved.

As a department head, I've come to appreciate that another challenging kind of search is for administrators and staff who affect the longer-term strategies of the department. I'll write a bit about this kind of search next time.

I haven't written about running in a while because I have not been able to run much for a while. On January 5, I came down with something that has kept me under the weather for three weeks. Fatigue has been the most onerous symptom. In that time until last Friday, I managed only four runs of 7 or 8 miles each. Every run seemed to provoke a small relapse or extension of the symptoms. I have taken the last week off in an effort to get back to 100%. That was my first full week off from running in at least three years. Even after my Sunday marathons, I have jogged by the next Thursday. It's hard to realize how much a habit is ingrained until I go cold turkey.

Finally this week I seem to be improving, and so this morning I ventured over to the track for a few miles. I should probably have taken it easy and jogged an easy 3 miles or so. But I planned to do at least 5, maybe 6, and in the end I ran 7. I did take it easy, though, at least for five of the miles, and ran a pace suitable for LSD (long slow distance). I'm a little sore, but it's the good kind of pain. So far, I'm just a bit tired and am hopeful that I'm still on the road to full health.

This break comes at an interesting time. Like Tiger Woods has done with his golf swing, I've been thinking about taking a small step backwards on the prospect of taking my training a leap forward. Throughout the winter, I've played with the idea of starting over with a new weekly plan. Rather than do my usual five or six days, with two mid-distance runs (one a speed workout) and a Sunday long run each week, I would pick some relatively small distance -- say 4 or 5 miles -- and run it every day for a couple of weeks. My idea is that I could develop a daily training schedule that doesn't tire me out but that does maintain a steady condition. One side effect is that I would lose my long-distance stamina. Then I could build the week back up slowly, starting with a couple of 7 or 8 milers. Add some speed here, some distance there, and I would be back up to the sort of mileage I'd like to run each week, 40-45 miles, but with rebuilt stamina and speed. The goal would be let my body relearn the distance and speed skills.

To do this right, I should probably consider a longer interim, say a couple of months, in which I do know running but instead cross train on a bike, in a pool, or on a tennis court. But I don't have Tiger-like patience just yet!

As it is, by recent standards I have now run very little since Christmas time, so maybe I'm rested enough to try something new to good effect. Trying to get over this cold-like virus is motivation to keep the mileage low for a while, and my eagerness to get back on the road is motivation to run every day.

The other complication right now is one that many folks can understand: snow. We received 10" of snow in a week a couple of weeks ago. This is, of course, hardly worth mentioning after what our friends in Denver, Oklahoma, Portland, and the like have faced recently. But the effect is the same. Running trails are covered. Roads are artificially narrow, and slippery in places. Sidewalks are only occasionally passable. The challenge is to find routes that I can run reliably and safely. It seems that each winter creates its own set of best running routes. Then there are the temperatures. But you know what I've said before, you know you're a runner if.... I will find a way.

Good running to you all. I look forward to getting back into a rhythm and seeing what running teaches me about programming, software development, and teaching this year.

Our dean is relatively new in his job, and one of the tasks he has been learning about is fundraising. It seems that this is one of the primary roles that deans and other to-level administrators have to fill in these days of falling state funding and rising costs.

This morning he gave his department heads a short excerpt from the book Asking: A 59-Minute Guide to Everything Board Members, Volunteers, and Staff Must Know to Secure the Gift. Despite the massive title, apparently each chapter of the book is but a few chapters, focused on a key lesson. The excerpt we received is on this kernel: Donors give to the magic of an idea. Donors don't give to you because you need money. Everybody needs money. Donors give because there is something you can do.

For some reason, this struck as a lesson I have learned over the last few years in a number of different forms, in a number of different contexts. I might summarize the pattern as "It's not about me." Donors don't give because I need; they give because I can do something, something that matters out there. In the realm of interpersonal communication, the hearer is the final determinant of what is communicated. Listeners don't hear what I say; they hear what they understand me to have said. The blog Creating Passionate Users often talks about selling how my book or software is about empowering my users -- not about me, or any of the technical things that matter to me. The same applies to teachers. While in an important sense my Programming Languages course is about the content we want students to learn, in a very practical sense the course is about my students: what they need and why, how they learn, and what motivates them. Attending only to my interests or to the antiseptic interests of the "curriculum" is a recipe for a course almost guaranteed not to succeed.

Let's try this on. "Students don't learn because you think they need something. They learn because there is something they can do with their new knowledge." They learn because the magic of an idea.

That sounds about right to me. Like any pattern taken too far in a new context, this one fails if I overreach, but it does a pretty good job of capturing a basic truth about teaching and learning. Given the many forms this idea seems to take in so many contexts, I think it is just the sort of thing we mean by a pattern.

People you've got the power over what we do
You can sit there and wait
Or you can pull us through
Come along, sing the song
You know you can't go wrong

-- Jackson Browne, "The Load-Out"

Every group of students is unique. This is evident every time I teach a course. I think I notice these differences most when I teach a course Programming Languages, the course I'm teaching this semester.

In this course, our students learn to program in a functional style, using Scheme, and then use their new skills to build small language interpreters that help them to understand the principles of programming languages. Because we ask students to learn a new programming style and a language very different from any they know when the enter the course, this course depends more than most on the class's willingness to change their minds. This willingness is really attribute of each of the individuals in the class, but groups tend to develop a personality that grows out of the individual personalities which make it up.

The last time I taught this course, I had a group that was eager to try new ideas. These folks were game from Day 1 to try something like functional programming. Many of them had studied a language called Mumps in another course, which had shown them the power that can be had in a small language that does one or two things well. Many of them were Linux hackers who appreciated the power of Unix and its many little languages. Scheme immediately appealed to these students, and they dove right in. Not all of them ended up mastering the language or style, but all made a good faith effort. The result was an uplifting experience both for them and for me. Each class session seemed to have a positive energy that drove us all forward.

But I recall a semester that went much differently. That class of students was very pragmatic, focused on immediate skills and professional goals. While that's not always my orientation (I love many ideas for their own sake, and look for ways to improve myself by studying them), I no longer fault students who feel this way. They usually have good reasons for having developed such a mindset. But that mindset usually doesn't make for a very interesting semester studying techniques for recursive programming, higher-order procedures, syntactic abstractions, and the like. Sure, these ideas show up -- increasingly often -- in the languages that they will use professionally, and we can make all sorts of connections between the ideas they learn and the skills they will need writing code in the future. It's just that without a playful orientation toward new ideas, a course that reaches beyond the here-and-now feels irrelevant enough to many students to be seem an unpleasant burden.

That semester, almost every day was a chore for me. I could feel the energy drain from my body as I entered the room each Tuesday and Thursday and encountered students who were ready to leave before we started. Eventually we got through the course, and the students may even have learned some things that they have since found useful. But at the time the course was like a twice-weekly visit to the dentist to have a tooth pulled.

In neither of these classes was there only the one kind of student. The personality of the class was an amalgam, driven by the more talkative members or by the natural leaders among the students. In one class, I would walk into the room and find a few of them discussing some cool new thing they had tried since the last time we met; in the other, they would be discussing the pain of the current assignment, or a topic from some other course they were enjoying. These attitudes pervaded the rest of the students and, at least to some extent, me. As the instructor, I do have some influence over the class's emotional state of mind. If I walk into the room with excitement and energy, my students will feel that. But the students can have the same effect. The result is a symbiotic process that requires a boost of energy from both sides every class period.

We are now two weeks into the new semester, and I am trying to get a feel for my current class. The vocal element of the class has been skeptical, asking lots of "why?" questions about functional programming and Scheme alike. So far, it hasn't been the negative sort of skepticism that leads to a negative class, and some of the discussion so far has had the potential to provoke their curiosity. As we get deeper into the meat of the course, and students have a chance to write code and see its magic, we could harness their skepticism into a healthy desire to learn more.

Over the years, I've learned how better to respond to the sort of questions students ask at the outset of the semester in this course. My goal is to lead the discussion in a way that is at the same time intellectually challenging and pragmatic. I learned long ago that appealing only to the students' innate desire to learn abstract ideas such as continuations doesn't work for the students in my courses. In most practical ways, the course is about what they need to learn, not about what I want blather on about. And as much as we academics like papers such as Why Functional Programming Matters -- and I do like this paper a lot! -- it is only persuasive to programmers who are open to being persuaded.

But I've also found that pandering to students by telling them that the skills they are learning can have an immediate effect on their professional goals does not work in this sort of course. Students are smart enough to see that even if Paul Graham got rich writing ViaWeb in Lisp, most of them aren't going to be starting their own companies, and they are not likely to get a job where Scheme or functional programming will matter in any direct way. I could walk into class each day with a different example of a company that has done something "in the real world" with Scheme or Haskell, and at the end of the term most students would have perceived only thirty isolated and largely irrelevant examples.

This sort of course requires balancing these two sets of forces. Students want practical ideas, ideas that can change how they do their work. But we sell students short when we act as if they want to learn only practical job skills. By and large they do want ideas, ideas that can change how they think. I'm better at balancing these forces with examples, stories, and subtle direction of classroom discussion than I was ten or fifteen years ago, but I don't pretend to be able to predict where we'll all end up.

Today we begin a week studying Scheme procedures and some of the features that make functional programming different from what they are used to, such as first-class procedures, variable arity, higher-order procedures, and currying. These are ideas with the potential to capture the students' imagination -- or to make them think to themselves, "Huh?" I'm hopeful that we'll start to build a positive energy that pulls us forward into a semester of discovery. I don't imagine that they'll be just like my last class; I do hope that we can be a class which wants to come together a couple of times every week until May, exploring something new and wonderful.

Three thoughts from recent reading. From a professional standpoint, one is serious, one is light, and one is visionary. You'll have to decide.

Understanding the New

In their New Yorker article Manifold Destiny, on the social drama that surrounded Grigory Perelman's proof of the Poincaré conjecture, Sylvia Nasar and David Gruber write:

On September 10, 2004, more than a year after Perelman returned to St. Petersburg, he received a long e-mail from Tian, who said that he had just attended a two-week workshop at Princeton devoted to Perelman's proof. "I think that we have understood the whole paper," Tian wrote. "It is all right."

Mathematics, the theoretical parts of computer science, and theoretical physics are different from most other fields of human knowledge in a way that many folks don't realize. The seminal advances in these areas create a whole new world. Even the smartest, most accomplished people in the field may well not understand this new world until they have invested a lot of time and effort studying the work.

This should encourage those of us who don't understand a new idea immediately the first time through.

Dressing the Part

In Why I Don't Wear a Suit and Can't Figure Out Why Anyone Does!, America's most X-generation sports owner, Mark Cuban, writes:

Someone had once told me that you wear to work what your customers wear to work. That seemed to make sense to me, so I followed it, and expected those who worked for me to follow it as well.

This is good news for college professors. If you believe the conventional wisdom these days, our customers are our students, and their dress is the ultimate in casual and comfortable. I can even wear shorts to class with little concern that my students will care.

But what about all of our other customers -- parents, the companies that hire our students, the state government, the taxpayers? They generally expect something more, but even still I think that academics are unique among professionals these days in that almost everyone cuts us slack on how we dress. Or maybe no one thinks of us as professionals...

Now that I am a department head, I have made adjustments in how I dress, because my audience really is more than just my students. I meet with other faculty, higher-level administrators, and members of the community on a regular basis, and where they have expectations I try to meet or exceed them. Cuban is basically right, but you have to think of "customer" in a broader sense. It is "whoever is buying my immediate product right now", and your product may change from audience to audience. The dean and other department heads are consuming a different product than the students!

Controlling the Present and Future

Courtesy of James Duncan Davidson, another quote from Alan Kay that is worth thinking about:

Alan Kay has always encouraged computer scientists to take ownership of the tools they use. Why should we settle for the word processor that we are given by the market? Or the other basic tools of daily computer use, or the operating system, or the programming languages that we have been handed? We have the power to create the tools we use. In Kay's mind, we have the obligation to make and use something better -- and then to empower the rest of the users, by giving them better tools and by making it possible for them to create their own.

Tiger Woods recently won the PGA's Player of the Year for the eighth time in his ten-year professional career. Since 1990, no other player has won the award more than twice. He is widely considered the most dominant athlete in any sport in the world -- which is saying a lot when you consider the amazing runs that tennis's Roger Federer and cycling's Lance Armstrong have had during Tiger's own run.

Woods is great, but he also stands out for something else: his remarkable efforts to get better. Now, most pros are continually working on the games, trying to improve their skills. Woods has taken this effort to a new level, by completely rebuilding his swing twice during his professional career. Sportswriter Leonard Shapiro describes Woods's most recent reconstruction, back in 2004 and early 2005. In 2004, a lot of commentators thought that Tiger had perhaps peaked, as other players on the Tour had been winning the majors and left him as just another competition. Tiger wasn't striking the ball as well, and his tee shots were errant. He seemed to have gotten worse. But suddenly in 2005, he returned to the top of the leaderboard with a vengeance and had one of the all-time great years in PGA history.

You see, while Tiger was seemingly getting worse, he was actually getting better.

A golf swing is complex mechanical act. There is very little margin of error between a great shot and a merely good shot. At the top level of golf, the standard deviation is even smaller. When Tiger decided that he had reached a plateau in his game with his current swing, he knew that he had to develop an entirely new swing. And while he was building that new swing, using it on every shot for nearly eighteen months, he performed worse than he had with the old swing. Only after all that repetition, feedback, and adjustment did he have the swing he needed to regain his peak. And his new peak was even higher than the old one.

This progression from plateau to valley to new peak is not unique to Tiger or to golf swings. Any complex skill that depends on muscle memory requires the sort of repetition and feedback that usually results in degraded performance during the learning phase. The key to improvement in this phase is patience. Learning a new skill takes time, while we train our brains and bodies to execute their tasks in an accurate, repeatable way.

Mental skills, even ones that we carry out with more conscious attention, have this feature. Sometimes, we can make only small incremental improvements from our current skill base, but an effort to learn something radically different can alter our skill base in a qualitative way -- and result in radical improvements in our performance.

Many programmers know this. The last couple of years, a common new year meme among bloggers has been to learn a new language. Often the language is something very different from their daily tools of Java and XML and C. Haskell, Ruby, Scheme, and Smalltalk seem to show up on peoples' lists frequently precisely because they are so different. They offer the promise of a radical improvement in skill because to master them requires looking at problems and solutions in a radically different. You can't speak fluid Haskell or Scheme without coming to grips with a functional mindset. Even if list comprehensions, continuations, and tail recursion are not part of the programming language you use in your day job, understanding them can help you use that language in a new way. And who knows, those features may ultimately make their way into your day job's language -- either this one, or the next one.

Martin Fowler writes about his own experience crossing the improvement ravine on the way to new mastery. He even quotes Gerald Weinberg, whom I've mentioned occasionally since I first began blogging. Martin points out a couple of key insights. One is that sometimes the new thing doesn't work, at least for you. Worse, there is a Halting Problem complicating matters: you can't be sure if the technique has failed for you or if you just need to stick with it a little longer. The best hope for circumventing this problem is to have a good teacher working with you, whether in a classroom or one one one. Tiger had his coach, Hank Haney, to help him assess the state of his swing and decide to keep going, even during the darkest days of 2004. Working with colleagues or a trusted friend can also serve this purpose.

I think another key to this process is a sort of courage. It's hard to be patient while you're failing, or while you're struggling with a new idea. In this context, your teacher coach, or friend plays the important role of support system, encouraging you to stick with the process. As with almost anything, doing it over and over helps us to have the courage we need. Tiger's 2004 rebuild was the second such publicized episode of his career, and I'm guessing that having succeeded in the first helped him to remain steadfast during the second. One requires less courage as one feels less fear. But I think that I will always feel a real fear anytime I step way outside my expertise in an effort to get better. Maybe even a great one such as Tiger does, too. Courage will always play a role.

This notion of getting worse for a while in order to get better is on my mind right now because I have just begun a new semester in which I will try to teach Scheme and functional programming to a bunch of students who probably feel pretty comfortable in their imperative programming skills with Java, C++, and Ada. I have to help them see that mastering such a different new language, and especially style of programming, will require that they feel awkward for a while. The tried-and-true syntax, operators, idioms, and patterns no longer seem to work. That is scary. But it's worth going through this scary phase, practicing "the real thing" as much as they can. With practice and time, they will soon learn the new syntax, master the new operators, appreciate the new idioms and develop some of their own, and finally discover the new patterns that will make them better programmers than they were before.

My memory is always drawn back to two former students in particular who approached this in a Tiger-like fashion. They went home every night for three weeks or so and just tried to write good functional programs in Scheme. They read my examples and those from the textbook; they experimented with small modifications and then large ones, eventually trying to write whole programs. For a while this was painful, because their programs broke and my evaluation of their homework didn't result in the easy As to which they had become accustomed. But suddenly -- or so it seemed -- they got it. They were excellent functional programmers. The rest of their Programming Languages course went smoothly, as they could focus on the language concepts without having to worry about whether they could make Scheme work for them.

If the greatest golfer in the world, the most dominant athlete of a generation, can take the time to get worse for a while in order to get better, I think we all can. But do we have the patience and courage to take the chance and stay the course? And do we have the teachers and coaches who can help us along the way?

You may recall a risk I took a few weeks back -- I returned an exam to my CS 1 student on which the grades were disappointing to students, and me, and then later in the period asked them to assess the course and my teaching. No one can say that I tried to stack the deck, either by action or inaction!

I received my feedback today, and I all I can say is that the trust I placed in my students' judgment was well-deserved. The assessments were mostly positive -- actually, as good as I've ever had. Given the situation, I doubt that they were artificially high, and I can only hope that they reflect what my students thought. If they do, then the course was a success, both the media computation approach and my implementation of it. That is good news for the students, and for our department, which could use a solid cadre of new majors and minors moving through our program.

One question remains: Are these students prepared well enough for their subsequent courses? That is the ultimate criterion for success, and we won't know that until they have taken a few more courses. I'll be keeping my eyes open to their performance in coming terms.

Another question remains: Will the media computation approach succeed in other instructors' hands, or even in my hands after the initial rush of excitement I had teaching it the first time. The approach is in use at several other schools, so there is some evidence independent of our institution. We'll see how things go in coming semesters, with other instructors here trying the approach. (It's in place for at least one more semester, this one.)

I'm also curious to see how using the Python in the course, or some other lighter-weight interactive language. I'm not sure when, if ever, that might happen here. Curriculum, especially the first-year curriculum, is a hot potato in my department. But I think Ruby or Python might be a great way to appeal to an even broader audience, without losing the hard-core CS-leaning students.

1. When I ran the native OS X spellchecker on my last entry, it balked at "Spolsky", and suggested "Splotchy" instead. I don't know why I feel compelled to say so, but there. At least that's funnier than replacing Wozniak with wooziness.

2. You may notice that the links in the preceding paragraph are broken right now, and that all of my permalinks have been for a week or so, I guess. By broken, I mean that it doesn't take you to the 11/20/04 entry titled "Strange Blogging Occurrences" as it should. (At least it takes you to November 2004!) Our college web server underwent some migration and reconfiguration recently, and redirection of URLs seems to be a problem yet. I hope that the problem is fixed soon. In the meantime, my apologies for any inconvenience as you read.

Maybe if I had big companies bribing me to blog I would make more time in these busy days?

The one sort of freebie that faculty tend to receive are examination copies of textbooks. Some publishers, especially the smaller ones and the highest-scale one, tend not to send unsolicited copies and expect you to return requested exam copies if you don't adopt the text. But some of the major CS-oriented publishers are quite generous. Sometimes you have to ask, either on-line, through a rep, or at a conference, but sometimes unsolicited copies flow freely. The most recent impetus was the advent of the Java intro and data structures texts. I long ago lost count of how many such texts I've examined, both requested and unsolicited.

As Spolsky points out there is an ethical question at play. I think I've maintained a pretty healthy relationship with the textbook reps I've known, and I know some pretty well. A couple of my local reps have been serving my university for a long time, and some of the reps that work conferences such as OOPSLA and SIGCSE have been on that circuit for nearly as long as I. As long as I approach texts as potential adoptions, I can accept a copy for examination. As the text moves away from my core teaching areas, I begin to feel guilty about taking a book. Sometimes I feel a bit guilty even when a book lies right in my area of teaching -- if I really want the book. Somehow, getting something I really want for free seems wrong, even if there is a legitimate professional reason. Must have something to do with how I was raised.

Of course, working at a relatively small school, I don't have much to offer publishers even if I adopt a textbook as a result of some gift or other freebie. If I taught 500-person sections at Mega State, then maybe... but my 35-person sections, even as an annuity over several years, don't amount to much revenue for anyone. Nor have I blogged many book reviews (or book crushes), and the size of my readership hardly makes me a target of Massive Consolidated Publishing.

The one way that I could enrich myself in a meager way from all the unsolicited books is to sell them to one of the many book re-sellers than now troll our halls and inundate us with e-mail. I would never do that, because I want neither to gain financially from the books nor to encourage the book reseller business. If I do anything other than keep the book, I give it to a needy undergrad or grad student looking to do some extracurricular work. Someone can gain from the book that way. Perhaps I should return the book to the publisher, but I don't feel much of an incentive to spend my time undoing something that the publisher did on its own. My time is scarce enough as it is.

I do have one book review that I plan to do sometime soon, on Chris Pine's Learn To Program. This is intended as an intro book -- the first? -- using Ruby. When I hesitantly sent Andy Hunt of the Pragmatic Bookshelf an e-mail asking for an exam copy, he sent me one immediately. We haven't had a chance to offer a Ruby-based intro programming course yet, so I couldn't adopt the book at the time. But it's interesting enough to talk about in public. If I do blog on it, I will be fair and as objective as possible. I owe you -- and myself -- that much. And I think Andy and Chris would want that to.

In closing, I will recommend a piece of software, and the recommendation will expose me as an OS X guy. This probably eliminates whatever small chance I ever had of receiving, like Joel Spolsky, an offer to blog about a complementary "loaded Ferrari 1000 courtesy of Windows Vista and AMD". That is a risk I am willing to take.

I send a lot of e-mail. I send a lot of e-mail with attachments. I cannot count all the times I have sent a message that said "Attached is ..." or the "See the attachment." and yet forgot to attach the file. Until a couple of months ago, this was an increasingly frequent and frustrating behavior of mine.

The I discovered James Eagan's free Attachment Scanner Plugin for Mail.app. Problem solved. It recognizes every variation of "*attach*" that I've ever used, and every time it reminds me to attach the file if I haven't already. Paradise.

The plug-in solved a major problem for me. It is free. And to top that, Eagan wrote a fine tutorial on how he decoded Mail.app's private plug-in and wrote his plug-in. That's more than I could have asked for!

Mr. Eagan did not pay me to say that.

I was thinking that break time would be a great time to write a bit, both here and in my day job. But as Lance Fortnow writes, the academic world isn't nearly as quiet over the Christmas holidays as it used to be. I spent some of the time between Christmas Day and New Year's Day in my office working on some forward-dated Call for Proposal web pages for OOPSLA 2007 and some other time catching up on administrative and bookkeeping tasks. I also spent some time with my wife my daughters, enjoying family time that is so easily squeezed during the school year -- as much by their schedules as mine! Top it off with a whirlwind trip to Michigan and Indiana to visit extended family over the New Year's weekend, and suddenly I'm back in the office thinking about summer teaching schedules, graduate assistant assignments, and campus IT policies. I'm itching to write but trying to get a lot done, both here and at home, before the new semester begins in earnest.

I've noticed a pattern in my blogging. Whenever I go a few days without writing, I find that my first post is likely to be more personal than professional. It's almost as if I need to clear out my system a bit, priming the pump for what is to come. With a semester teaching what is probably my favorite course, Programming Languages, there will surely be plenty to say. And I have entries on the way dealing with people as diverse as Stephen King and Tiger Woods, and topics ranging from science and liberal education to Scheme to a review of my year in running shoes.

I'm not the sort of person makes New Year's resolutions. It was never a family tradition, and it never has appealed to me all that much as someone who believes in continuous feedback and improvement (even if I don't often practice what I preach). But I did see a quote this morning, in an inspirational e-mail message from writer Matthew Kelly, that gave me a little resolution buzz:

Preparation and anticipation play a powerful role in our lives; let's stop robbing ourselves of these gifts by doing everything at the last minute.

If I can take even a cautious step in this direction, I think I'll enjoy 2007 more than 2006.