Just a quick training update, only because I am even more surprised and pleased than I was after my last long run.
I am planning to close my long-distance training with the traditional 20-miler three weeks before race day. My goal for much of this season has been to try to run this 20-miler at my marathon goal pace -- 8:00 min/mile -- or close.
On Sunday, I did a 22.2-mile long run, five weeks before the marathon. The final time: 2:55:53! That's a minute and a half sub-goal pace.
Oh, and I managed negative splits on my clocked miles: 8:27, 8:09. 7:57, 7:40, 7:30, 7:10. That last was Mile 20!
I am pretty sure that I could have finished a full marathon in 3:30 on Sunday. This run came at the end of a 60-mile week, and a 122-mile fortnight.
Other than a longer than usual nap on Monday, and some sore quads Monday and Tuesday, my body showed no ill effects from the training run. I even played volleyball on Sunday evening.
At this point, I am as confident as I can be about my speed and endurance heading into the marathon. I just need to maintain my fitness level, perhaps improving the combination of speed and endurance a bit in my last few track workouts. My real focus now is on a good taper (rest!) and the right diet in the week before the race.
One of my favorite early episodes of the American sitcom Friends has a subplot focusing on Chandler as supervisor at work. When Phoebe comes to work part-time as his secretary, he learns that he is no longer "one of the guys". His charges talk about him as boss, imitate his idiosyncratic speaking inflections, and generally don't like him anymore. At first, his feelings are hurt, and then he just feels separated and a little lonely. Of course, Phoebe falls in with the gang and even takes to calling Chandler "Boss Man Bing".
Could it be any more obvious where I'm going with this?
There are moments when I know just how Chandler felt. Moving into a supervisory position creates a separation that can hardly be avoided. The Big Office Downstairs is, well, downstairs, out of the regular action that is a usual day among the faculty. Especially in these early days, while we become accustomed to our new roles relative to one another, it's almost unavoidable that some awkwardness will intrude on what used to be comfortable or even close relationships. And where relationships were already a little tense, tension becomes even more palpable.
That said, I am in a pretty good situation, at least compared to Chandler. I work with a pretty good group of people, and we all seem to be adjusting pretty well to the new situation. One of the things that made this job worth applying for -- in the presence of whatever problems the department may face -- is that, at bottom, we are a group of good people who have our sights on goals that we can all aspire to. We socialize well together and even play well together, as yesterday's department picnic and post-dinner volleyball game showed.
Besides, as far as I can tell, no one has developed a good Boss Man Wallingford impression yet. (Actually, I am the most likely mimic in the department, and you should hear me do me!)
However, in moments of dispiritedness -- brought on by the bad breaks of a day, by the fatigue of long hours and a deluge of new tasks to learn and do, or by my sagging biorhythms -- it's easy to feel left out. Sometimes the best thing to do is to seek out a friend and colleague just to chat. It doesn't matter about what, though talking about our latest classes or the minutiae of daily academic life bridges the gap quite nicely.
Academic departments have an advantage over many business environments in this regard. A department head is more "first among equals" than supervisor or manager, which means that in the long run it seems possible to drive the gap to epsilon, for a very low value of epsilon. There will always be certain decisions that the head has to make, but strong relationships and an understanding on the part of all that such decisions must be made can minimize the separation that these decisions bring to mind.
All of this requires some effort, though. Not the frantic denial that Chandler wants to execute on Friends, but simply working together, building trust in communication and decision making, sharing ideas, information, and -- whenever possible -- control over the department's course. But then I already knew that.
I can only determine how I behave and contribute to these relationships. That what I hope to do.
Ultimately, Chandler came to embrace the new relationship with his former compatriots, even playing along by giving them imitable material. I hope in my situation to create an environment in which we all feel like contributors, with me doing what I can to help the faculty take the department in the most productive direction possible.
Okay, somebody's gonna be working... this weekend.
I did my longest long run of the season on Sunday: four times around a 10 km loop in the local state park, for a rough total of 24.8 miles. This run came at the end of my longest training week, too, 61 miles. It was, I believe, my longest week ever.
Once again, I was pretty happy with the results. I knew that I needed to pace myself in order to complete this run, so I planned to begin gently. But, as slow as it seemed at the time, I must have felt better than I expected. My four "lap" times were 51:36, 51:01, 50:38, and 48:38. Negative splits! Even better, the first three were faster than all but the fastest split time for my recent 18-miler, over the same course.
I broke each lap into two parts that are roughly 5K each. Near the end of each of these parts, I clocked a single mile in order to gauge my pace. The eight miles, in order, were 8:36, 8:30, 8:33, 8:23, 8:27, 8:08, 7:40, and 7:27. Yes, I ran the 24th mile in 7:27.
Total time: 3:21:53. Color me pleased!
Later in the day, I went back to compare my time on this route with the same training runs for my previous two marathons. My log reminded me that I was unable to do this route last year, due to flooding from heavy rains in the preceding week or two. But back in 2002, I ran this route on September 21, as part of my then-longest (by far) week ever of 51 miles. I didn't run negative splits that year, though my fourth lap was my second fastest. The run took me 3:59:38. My improvement in two years was about 38 minutes.
Notice, too, how late my longest long run came in 2003. My 2004 24-miler came on the same weekend, September 19. By hitting 24 miles a month earlier this year, I have the luxury of being able to do two more long training runs: a 22-miler next weekend and a 20-miler exactly three weeks before the race date. I can focus these runs on pace management and speed, without having to worry about endurance.
At this point, I am guardedly optimistic that I can make a solid improvement on my marathon time from last year. The guardedness reflects the intrusion of reality... I took restroom breaks during the training run that I will hope not to take during the race. Those rests, however brief, improve running time at the cost of actual time. Plus, there is a big difference between early 8 ½-minute miles and early 8-minute miles. But I will also rest my body in the weeks leading up to the race, and I will do more to manage my diet and sleep. We'll see.
Doing this run reminds me just a bit about how grueling the marathon is. As happy as I was with my time, my quadriceps are still feeling it two days later. Over the course of the run, I lost eight pounds. (Don't worry; most of that comes back with a moderate-sized meal later in the day.) And I needed a nap on Monday, though I didn't get to take one. :-)
Back to the track tomorrow morning...
When I was a in school, I was a pretty good student. The first class I ever remember not "getting it" immediately was Assembler 2, at the beginning of my sophomore year in college. The feeling was a bit scary.
Our first assembler course was the "traditional" assembler course, in which we learned basic computer organization and the magic of MOV, JNE, and LD commands. But this was the early 1980s, and my school required a second course in this area. In the second quarter, we did more assembly language programming, but we also learned JCL and how to control an IBM 360/370 at a fine level of granularity from the moment execution began. Our card decks and key punches and assembly language programming became a bit more complicated.
For whatever reason, the different levels of abstraction in the 360/370, when combined with the massive gulf between the problems we were programming and assembly language, left my head spinning. I didn't get it. Good student that I was, I kept plugging away, doing what we were taught in class, getting mostly correct answers -- but not really understanding why. And when I did understand something, it did not feel natural. and scored well. But I was worried, because I didn't get it. I didn't feel like I was in control.
Then one morning, everything changed. There was no great epiphany, no flash of light. I was simply standing in the shower when I realized, ever so naturally, that it all made sense. I walked to class, and all was again right with the world.
Since that time, I have had this sort of experience a few more times. The learning process moves slowly for a while, with the effort exerted exceeding the gains in understanding. Then, there seems to be an acceleration in understanding, like compound interest on the effort exerted earlier in the process. Once I got used to the idea that this would happen, it wasn't so threatening to me, and I was able to proceed with relative confidence deep into new ideas that I wasn't getting -- yet. But there is always a nagging thought at the back of my mind that this is it -- I've finally reached a point I won't be able to get.
Runners have an idea that bears some resemblance to this upside-down learning process, called negative splits. The simplest form of negative splits is when the first half of a run is slower than the second half, but the idea generalizes to any number of splits. For the mathematically inclined among you, think of a monotonically decreasing sequence of split times.
In running, negative splits are generally considered a good thing. They are wise as a training strategy, as they ensure that you do not use up all of your energy too soon. Plus, they cause you to run faster at the end of the workout, which trains your body in the feeling of working hard when it is tired. They are often a wise racing strategy, too, for many of the same reasons. Many racing greats have set records running negative splits.
As I have learned over time, there is a corresponding danger -- going too slow in the beginning. If I am trying to get better, I need to be careful not to create negative splits by virtue of not working hard enough early on. In a race, this can waste the opportunity to reach a goal. But for endurance training, it's hard to go too wrong with negative splits. The goal is to do the miles, and negative splits maximizes the chance of completing the miles successfully.
Recently I wrote about my happiness with some long distance workouts. You will now notice that both my 20-miler and my 22-miler were characterized by negative splits. Much of my happiness comes not so much from running fast as from running faster as those long runs progressed -- in some cases, with eight or more miles increasingly faster than the previous.
I've come to realize that negative splits in learning, of the sort I experienced in that second assembler course, are also often a good thing. Learning requires our minds to change, and that change often takes time. Changing habits, practices, and expectations is hard, because our minds are well-suited to remembering and employing patterns of thought as a strength. Some of us even have a harder time than others changing mental habits. I am one of those people.
Runners use negative splits as an explicit strategy, but for the learner change often forces us to accept negative splits. They are simply cognitive and psychological reality. Coming to accept that, and treating negative splits as the way we sometimes must learn, can free us from a lot of fear and uncertainty. And surrendering that fear and uncertainty can help us learn even better.
Students should keep this in mind. (And remember, we are all students.) Teachers should keep this in mind, too. We need to take negative splits into account for many or all of our students, especially with the most challenging or abstract material. This is one of the elements of teaching that calls for a little cheerleading, a little reassurance to students that they should hang in there with the tough stuff, with the promise of it all coming together sometime soon.
Leaders of every sort -- even department heads -- need to keep this principle in mind, too. Introducing change to an organization has all the hallmarks of trying to learn new habits and practices. People feel fear and uncertainty. This is complicated by the fact that sometimes the change must come to personal interactions, which carry a lot of extra psychological baggage with them. Negative splits may be a wise strategy for the leader, introducing small, easier-to-master changes first and only accelerating when people gain confidence and realize their own strength.
That old assembler course... I had one of my favorite CS professors ever in that course, one who taught me so much about systems, software, and professionalism. I still have the textbook on my bookshelf, too: System 360/370: Job Control Language and the Access Methods by Reino Hannula. Early in that semester, the name "Hannula" raised fear in students' hearts, was veritable poison to the ears. When we all got it, it became a beloved totem of our collective experience. And the greatest lesson we learned in the course probably wasn't IBM JCL -- as cool as it was -- but the idea of negative splits.
Earlier this week, I learned a bit about how to use my university's financial information system. It is an application built almost entirely out of the box using Oracle E-Business Suite tools. By the time I left the room, I was embarrassed for my discipline.
My college secretary gave an informal tutorial to me, another new head, and our acting dean. We learned that it is not straightforward to do most of the tasks that we might want to do. What was worst, from most point of view as a software developer, is that the complexity of the interface matched or exceeded the complexity of the underlying data.
The primary users of this system -- secretaries and office personnel -- seem to be good troopers. They acknowledge the complexity of the system with mostly good cheer and seem intent on mastering the complexity of the interface. Then again, perhaps they are just being kind when they speak to me, a "computer person", and are burning their mousepads -- and me in effigy -- when I'm not around. I wouldn't blame them.
The administrators I've talked to, who have to use the system to manage their budgets and personnel, openly grumble about the system.
To be fair, this software solves a very large problem in our medium-sized institution. As an undergraduate, I worked as a programmer in administrative computing at my alma mater. The database with which we worked seemed uncommonly complex at the time. Of course, it wasn't; I was just inexperienced in the ways of computing. Financial information systems these days are even more complex, managing the interactions among several classes of employees and supervisors, payroll and grants and foundation accounts, departments and units and colleges, .... On top of that are issues of security and responsiveness. I don't doubt that our financial information system is more complex than any IS with which I have worked.
But users shouldn't have to see any more of this complexity than necessary. Users of our system seem to see nothing but complexity. Layers of jargon-laden links that serve as menus. Several cryptic codes that must be entered before you can reach data on any form. Few, if any, defaults. Few, if any, shortcuts.
The giveaway that the system is too complex for its own good? Regular users have asked system administrators to create a "cheat sheet", a page containing advice of the sort, "If you want to see data on x, do the following..." Why can't frequent, knowledgeable users find their way to commonly-needed data already?
The good news for users here is that the team that administers our system has produced good on-line training material. (Someone at OracleAppsBlog thinks so, too.) Good. But why should the main focus of a software unit be to produce good documentation? As we in the agile community know, the need to write better comments usually indicates the need to write better code. The need for excellent training materials implies a need for a better interface.
I don't want to be too hard on Oracle. I know that the task is complex, and I know that Oracle isn't the only computing company producing software that users can't use, at least comfortably. This system is just one example, albeit a very good one, of a general problem in our industry. But I guess I do expect more from "the world's largest enterprise software company" ...
And I'm certainly not complaining about the UNI folks who have assembled our information system. They built the system on a relatively small budget using standard Oracle code, interface components, and style sheets. But, as a user, I wish that we could do better.
Even sadder in these days of budget cuts in higher education, my university has almost certainly sunk in excess of $100,000 into this system and thus are committed to the long-term costs of keeping it functional. When I add in training costs, the total cost probably goes up significantly. When I add in the cost of the time lost battling the system ... I don't want to think about it.
We in software development do a disservice to users when we tell them, explicitly or implicitly, that things have to be complex, hard to use, uncomfortable, painful. We tell them that they don't understand. We tell them that they must just not be smart enough to use technology. We are wrong, and they should be told that.
In thinking about concrete, relatively low cost steps we would take to improve the quality of user experience, a friend and I focused on the fact that most accesses into the system recurring. While I was being "trained", I repeatedly heard "you don't need to worry about these options. You'll never use them. Focus on this subset of options...." How about something simple, which Mac OS has had forever: an easily-accessible recent items menu? Or a "most-frequently accessed reports" menu? I am guessing that, within a few uses, most administrators would never have to venture outside one of these lists. More frequent users might need a longer list, but that's no problem.
Upon further inspection, it seems that users of our system can build their own shortcuts lists, by "customizing" their own "portlets". (Portlet?) But I am not yet certain how to use this interface feature properly. I must not be smart enough to use this system. Maybe I don't understand. Sorry, I don't believe that -- about me or about any of the regular users of this system.
We know how to do better. Most developers know better -- or should.
This evening I had the pleasure of attending a reception here as a part of Senator Charles Grassley's Ambassadors Tour. Every two years, Senator Grassley brings a delegation of ambassadors and embassy representatives for a tour of the state of Iowa. This year's delegation consisted of representatives of over 70 countries. They will spend five days in Iowa, visiting various Iowa businesses, in hopes of creating opportunities for international collaboration -- especially business connections. Senator Grassley is a UNI alumnus and brings his tour to our campus every other time or so.
I had the opportunity of chatting with representatives from four continents, though I spent most of my time with delegates from the Republic of Congo, Russia, and Taiwan. Having "computer science" on my name tag seemed to attract folks' attention. Some countries seek to build up their computing infrastructure in order to participate more fully in the information economy. Others seek to develop connections to utilize existing computing industries. Still others found computers to be a familiar way to start a conversation, even if they weren't so interested in building up new computing-related connections with UNI.
My conversations this evening remind of just how much we all have in common. When Americans think of the Congo, most probably don't think about colleges and businesses trying to do the same things they do here at home. The news we hear tends to be of extraordinary events, especially natural and man-made disasters. I had a chance to give my condolences to the senior diplomat from Cyprus for the recent plane crash in Greece that killed over one hundred of his compatriots. Computing notwithstanding, we all live in very much the same world.
BTW, Senator Grassley is a good guy, and he has been good to his alma mater while serving in the legislature. Obligatory running trivia: Senator Grassley is an active runner, even in his 70s. He remains the only U.S. legislator whom I know I've defeated in a race, a 5K in a nearby rural town several years ago. I usually, um, neglect to tell anyone that he was just about to turn 70 at the time! (If I've defeated anyone else with a national profile, it was surely in the 2003 Chicago Marathon. That was a big crowd of runners! Then again, I was behind many of them.)
After a couple of weeks in the Big Office Downstairs, I've been reminded how important some elements of human psychology are to group dynamics:
A close friend of mine is police chief of a small town back in my home state. When I was visiting him a couple of weeks ago, he shared some of his experience as an administrator. He jokingly said that his job consists in three roles: manager of budgets and schedules, leader among his staff and community, and daycare provider. We both knew what he meant. Neither of us really thinks of our administrative jobs in such a condescending way, but it is clear that working with people is at least as important as the "paper pushing" elements of the job, and in some situations can dominate.
That said, the paper-pushing side of things creates challenges, too. I am already finding the constant flow of information -- new things to do, new items for the calendar, new ideas to try out -- to be overpowering. In response, Remind and VoodooPad have become my friends. (As has the Remind widget.)
Remind is a plain text Unix calendar tool. I considered using iCal for a while, but my preference for plain text data and low-frills interfaces pushed me toward Remind. After only a week, I was quite happy. I can add new entries to my databases with any editor, and I can script other applications to add them for me. The one thing I'd like is a better way to view weekly or monthly calendars. By default, Remind prints out days in fixed-width columns that result in the squashing and breaking of words. Of course, that's the beauty of a plain-text tool: If I want a different interface to my data, it is straightforward to write one. (I feel a student project coming on...)
VoodooPad is just way cool. I tried OmniOutliner for a few months after first accepting my new position, when I was busily creating list of ideas and to-dos. I liked it all right, but it never felt natural to me. VoodooPad makes it easy to create links to new pages, using either CamelCase or command-L on any text selection, so I get the effect of collapsible sub-lists in wiki form. The program is also integrated with other OS X apps and services, such as Address Book and Mail, so I get free linking to my other on-line data and can launch an e-mail message with a single click. In one tool, I have a note taker, a wiki, a to-do list manager, and a decent text editor. There's a reason that VoodooPad is one of MacZealot's top 10 shareware apps of 2005.
Using great tools means that I can eventually focus my energy on the Big Picture. I say "eventually" because, right now, mastering some details is the Big Picture.
Not too long ago, I wrote about an an opinion piece by Sanjeev Arora and Bernard Chazelle that, in part, decried the lack of good story-telling by computer scientists. Not the stories we tell each other, because there are plenty of those and many are wonderful. What's missing are stories we tell the rest of the world about just how thrilling our discipline is and can be.
A recent post at Ernie's 3D Pancakes returns to this theme of story-telling. The article begins as a discussion on Bill Gates' much-discussed interview with Maria Klawe. Toward the end, though, Ernie gets to what for me was his killer point. First, he catalogs the most common stories that non-CS folks hear and tell about computing:
When people do hear or tell the "Oh Wow! This Is So Cool!", he writes, it's usually just a cover for one of the other story lines.
And here is the paragraph that we computer scientists should wake up and recite each day:
This lack of stories is an endless source of frustration for those of us who say "Oh Wow!" every day. We see power and beauty in computer science, even while we rage against the limitations of the technology that grows out of it. We see our field not (just) as a way to make boxes that beep, but as a fundamentally new way of thinking about the world. We are craftsmen, taking great satisfaction in the structures we build. We drag abstractions kicking and screaming from Plato's cave, and we make them real. We are explorers, proud of our hard-won discoveries but humbled by the depth of our ignorance. We have changed the world, utterly and irreversibly. Our influence on your daily life may be less immediate than the influence of doctors, lawyers, politicians, bankers, and soldiers, but it is no less profound. And we are just barely getting started.
More importantly, we need to find entertaining and compelling ways to tell our friends and the rest of the world -- and, yes, our sons and our daughters.
After a week impersonating one of the Two Men and a Truck guys, I'm finally back to reading a bit. Brian Marick wrote several articles in the last week that caught my attention, and I'd like to comment on two now.
The first talked about why Brian thinks the agile movement in software development is akin to the British cybernetics movement that began in the late 1940's. He points out three key similarities in the two:
I don't know much about British cybernetics, but I'm intrigued by the connections that Brian has drawn, especially when he says, "What I wanted to talk about is the fact that cybernetics fizzled. If we share its approaches, might we also share its fatal flaws?"
My interest in this seemingly abstract connection would not surprise my Ph.D. advisor or any of the folks who knew me back in my grad school days -- especially my favorite philosophy professor. My research was in the area of knowledge-based systems, which naturally took me into the related areas of cognitive psychology and epistemology. My work with Dr. Hall led me to the American pragmatists -- primarily C. S. Peirce, William James, and John Dewey. I argued that the epistemology of the pragmatists, driven as it was by the instrumental value of knowledge for changing how we behave in particular contexts, was the most appropriate model for AI scientists to build upon, rather than the mathematical logic that dominates most of AI. My doctoral work on reasoning about legal arguments drew heavily on the pragmatic logic of Stephen Toulmin (whose book The Uses of Argument I strongly recommend, by the way).
My interest in the connection between AI and pragmatic epistemology grew from a class paper into a proposed chapter in my dissertation. For a variety of reasons the chapter never made it into my dissertation, but my interest remains strong. While going through files as a part of my move last week, I came across my folder of drafts and notes on this. I would love to make time to write this up in a more complete form...
Brian's second article gave up -- only temporarily, I hope -- on discussing how flaws in the agile movement threaten its advancement, but he did offer two suggestions for how agile folks might better ensure the long-term survival and effect o their work: produce a seminal undergraduate-level textbook and "take over a computer science department". Just how would these accomplish the goal?
It's hard to overestimate the value of a great textbook, especially the one that reshapes how folks think about an area. I've written often about the ebbs and flows of the first course in CS and, while much of the history of CS1 can be told by tracing the changes in programming language used, perhaps more can be told by tracing the textbooks that changed CS1. I can think of several off-hand, most notably Dan McCracken's Fortran IV text and Nell Dale's Pascal text. The C++ hegemony in CS 1 didn't last long, and that may be due to the fact that no C++-based book ever caught fire with everyone. I think Rick Mercer's Computing Fundamentals with C++ made it possible for a lot of instructors and schools to teach a "soft" object-oriented form of OOP in C++. Personally, I don't think we have seen the great Java-in-CS1 book yet, though I'm sure that the small army of authors who have written Java-in-CS1 books may think differently.
Even for languages and approaches that will never dominate CS1, a great textbook can be a defining landmark. As far as OOP in CS1 goes, I think that Conner, Nigidula, and van Dam's Object-Oriented Programming in Pascal is still the benchmark. More recently, Felleisen et al.'s How to Design Programs stakes a major claim for how to teach introductory programming in a new way. Its approach is very different from traditional CS1 pedagogy, though, and it hasn't had a galvanizing effect on the world yet.
An agile software engineering text could allow us agile folks to teach software engineering in a new and provocative way. Many of us are teaching such courses already when we can, often in the face of opposition from the "traditional" software engineers in our departments. (When I taught my course last fall, the software engineering faculty argued strongly that the course should not count as a software engineering course at all!) I know of only agile software engineering text out there -- Steinberg and Palmer's Extreme Software Engineering -- but it is not positioned as the SE-complete text that Brian envisions.
Closer to my own world, of course, is the need for a great patterns-oriented CS1 book of the sort some of us have been working on for a while. Such a text would almost certainly be more agile than the traditional CS1 text and so could provide a nice entry point for students to experience the benefits of an agile approach. We just haven't yet been able to put our money where our mouth is -- yet.
On Brian's three notes:
That doesn't mean that some of us aren't trying. I'm chairing OOPSLA's Educators' Symposium again this year, and we are leading off our day Dave West and Pam Rostal's Apprenticeship Agility in Academia, which promises a firestorm of thinking about how to teach CS -- and software development and agility and ... -- differently.
Why "take over a computer science department"? To create a critical mass of agile-leaning faculty who can support one another in restructuring curricula, developing courses, writing textbook, experimenting with teaching methods, and thinking Big Thoughts. Being one among nine or 15 or 25 on a faculty means a lot of hard work selling a new idea and a lot of time isolated from the daily conversations that help new ideas to form and grow. OOPSLA and Agile 200x and SIGCSE only come once a year, after all. And Cedar Falls, Iowa, is far from everywhere when I need to have a conversation on agile software development right now. So is Raleigh, North Carolina, for that matter, when Laurie Williams could really use the sort of interaction that the MIT AI Lab has been offering AI scientists for 40 years.
Accomplishing this takeover is an exercise left to the reader. It is a slow process, if even possible. But it can be done, when strong leaders of departments and colleges set their minds and resources to doing the job. It also requires a dose of luck.
My latest training cycle for the Twin Cities Marathon has gone quite well. I train in three-week cycles, consisting of two weeks of increase in mileage and effort followed by a "consolidation" week. The consolidation week gives my body a chance to recover from the new stresses, to rest a bit, and to prepare for new stresses to come. In my last running post, I wrote of the second hard week of my first cycle, in which I ran a fast 18-miler, and the slow, tired recovery week that followed.
I'm now into the third week of my second training cycle. In each of the first two weeks, I ran solid 7x1200m work-outs. But the long runs are what I feel best about.
On July 31, I ran a 20-miler in Muncie, Indiana, the home of my alma mater. The Delaware Greenways rails-to-trails bike trail offered an ideal route: flat, scenic, and toilet facilities. I ran ten miles from downtown Muncie to the neighboring town of Gaston and back. The first ten miles felt good, varying between 8:40 min/mile and 8:20 min/mile. When I reached Gaston, I felt strong enough to pick up the pace. What followed was, for me, an amazing eight-mile stretch:
8:07 - 8:07 - 8:03 - 8:02 -
7:59 - 7:53 - 7:25 - 7:34
Yes, I ran my 17th mile in 7:25. And I followed it with a 7:34 18th mile. At the end of the run, my feelings were a mixture of elation and amazement. Never before could I have done such a training run.
Yesterday, I ran a 22-miler here at home. The route consisted of my 18.6-mile route from a few weeks back, plus 1.8 miles to and from the trail loop. After running repeats only two days before, I wasn't ready to start fast, and I expected to go relatively slow and easy for the whole run -- just doing the miles to build stamina.
And did I start slow. My first 8+-miles were at an over-9:00 min/mile pace. But then I ran the middle 10K at an 8:43 min/mile pace, including an 8:15 mile near the end. Feeing stronger than expected, I decided to try to pick it up for the third 10K loop through the park. The result was a 7:54 min/mile pace, including miles of 7:46 (17th mile) and 7:22 (19th mile)! On the return home, I finished faster than I had started, for a grand total of under 3 hours, 9 minutes. Again, my feelings were a mixture of elation and amazement. Didn't I run a super-fast 20-miler last weekend? And a 7x1200m workout on Friday? Where is this strength coming from.
Practice. Many miles over many, many months. Except for the tragically gifted, it doesn't happen any other way.
I know, of course, that in the larger world of running my times are nothing special. But they are special to me.
Today, I took a well-deserved nap at the office, in the midst of beginning my new job duties. Being better is more fun, but it can also be tiring!
This week, I recover with fewer miles (49, instead of 54.5 and 55.5, respectively) and slower times. But this week should prepare me for my longest training run -- 24 miles -- and the two 60-mile weeks that make up my third training cycle. After that, one last 20-miler before I taper home to race day.
My term as department head began on Monday. I feel a bit overwhelmed with all I'd like to do right: plan for the long term, plan for the short term, learn more about our budget, create a list of faculty committees to assemble, meet individually with more faculty members about their goals and interests for the year, sift through all the notes I took in various meetings this summer, .... I have a natural desire to do it all at once, to be up to speed and at full capacity right away.
I also feel a nagging, almost subconscious apprehension that I won't do as well as I have imagined I might. In my application and interview for the position, I made some strong claims about openness, transparency, respect, fairness, and leadership. Now the promises made in the safety of no responsibility meet the reality of responsibility.
Oft expectation fails, and most oft there
Where most it promises; and oft it hits
Where hope is coldest, and despair most fits.
-- William Shakespeare
All's Well That Ends Well (II, i, 145-147)
I think that my best course of action in the face of seemingly overwhelming possibilities and a fear of failure is familiar to many of you: approach the task in an agile fashion. Take small, measurable steps. Communicate with my team, and let them contribute their many ideas and talents. Get feedback wherever possible, and use it to improve both the process and content of my work.
I've been think about how I might adapt ideas from Scrum and XP as explicit practices in the administrative side of my job. My thoughts are ill-formed at this point, so they are read neither for implementation nor description just yet. But I think a big visible chart is in the offing.
The key is to keep moving, to be making progress in concrete ways.
When George Hellmeier of Bellcore received the Founders Award from the National Academy of Engineering, he related the tale of his first discovery in liquid crystal technology. When he told Vladimir Zworykin that he had "stumbled upon" his discovery, Zworykin replied "... to stumble, one must be moving."
Sadly, the moving that is most occupying my mind and time these days is moving my office. In 13 years here and another 10 before that as a student of CS, I have collected a lot of book. And a lot of papers. And a lot of software -- on 5-¼" floppy, 3-½" floppy, zip disks, and CDs. In the depths of a filing cabinet, I found shrink-wrapped copies of Microsoft Windows 95 and Office and Visual Studio. And cables for 1992 Mac Quadras. On top of most all of this was a layer of dust that betrays my lack of cleaning over the last few years. I hope to have things set up in my new office by the end of the week so that I can get down to the real business of leading my department.