Well, the Gringo did it again. Lance Armstrong finished his professional racing with a dominating yet relaxed performance in the 2005 Tour de France. (Our friend Santiago finished 51st. A disastrous Stage 14 did him in.)
If you watched any of the interviews Lance gave over the last few days of the tour, you could see that he really enjoys racing, competing, and winning. He relished the challenge that the T-Mobile and CSC teams threw at him in the mountains. He would have enjoyed the raw challenge of scaling the Alps and Pyrenees had he ridden alone, but having teams of riders try to take his yellow jersey made them all the sweeter. And his wonderful closing time trial to cement his edge placed a perfect exclamation on his tour career.
Watching Lance these last few years has reminded me that being good is fun, as the folks at Creating Passionate Users recently wrote:
My running coach told me a few years ago, "It's just more fun when you're faster." I wasn't sure what he meant; I was just trying to get back in shape and do a decent 10K. But once I started training with much better runners, and began pushing myself and keeping my splits and timing my speed work... it was more fun. And it wasn't like I had any illusion of being competitive. Being better is just more fun.
You mean running repeats is fun? Yes.
No, not every moment. A few weeks ago, I had one of those days that, in isolation. wasn't as much fun as I would have liked. Getting back to form in my 1200m interval training has been hard this season. The week after the not-so-fun day, I managed to do 6x1200m, but the last one repeat was slower than I had wanted it to be. Last week, I just wasn't motivated to run fast, so I skipped the work-out in favor of a steadier 9.5-mile run.
My fatigue last week was a surprise until I sat down to compute my paces for my runs the previous week. In addition to the 6x1200m work-out on Wednesday and a 10-mile tempo run on Friday, I had done an 18.5-miler on Sunday. No big deal... until I see that I ran it in 2:25:37 -- an average pace of 8:01 min/mile. That is my marathon goal pace for October!
Being better is more fun. I have no illusions that I am fast, or that I will challenge even for an age group prize in the Twin Cities. This is about challenging myself, and getting better. It feels good.
This morning, I hit the track at 5:15 AM, earlier than usual so that I could get a bit more done at the office before a four-day weekend mini-vacation. It was cool, unusual after a month of 90-degree highs and 70-degree lows, but perfect for a work-out. As the sun rose, I knew that today was finally a good day of repeats. As I started my fifth, I knew that I would reach the days goal. In the end, 7x1200m, all in target time or better, with the seventh repeat being the fastest of all.
Being better is more fun. But without the local moments of less fun a few weeks ago, I wouldn't have been better today -- either in setting goals or achieving them. As I quoted Merlin Mann a few days ago in the context of knowing ourselves as well as we know our tools:
Making improvements means change and often pain along the way. It's hard to get better, and good tools like these can definitely ease the journey. I guess I'm proposing you try to understand yourself at least as well as the widget you're hoping will turn things around.
One interview moment with Lance Armstrong stuck with me last weekend. When asked what he would miss most about racing, he said that he would never again be in as good a shape as he is today -- and he would miss that most of all. Not the yellow jerseys or the wins or the accolades and adulation that come with them, but the simple state of being in the best possible shape. I know the feeling. Of course, I have an advantage on Lance -- I didn't start working hard at my running until a little more than two years ago, when I started training for my first marathon. That means my body, while old, is still relatively fresh. So is my mind. I hope to keep getting better for a few more years...
University-level instructors of mathematics and science have become increasingly concerned about the level of preparation for their disciplines that students receive in elementary and high school. For example, Tall, Dark, and Mysterious and Learning Curves both describe life in the trenches teaching calculus and other entry-level math courses at the university. We in computer science see this problem manifest in two forms. We, too, encounter students who are academically unprepared for the rigors of computing courses. However, unlike general education math and science, CS courses are usually not a required part of the students' curriculum. As a result, we begin to lose students as they find computing too difficult, or at least difficult enough that it's not as much fun as students had hoped for. I believe that this is one of the ingredients in the decline of enrollment in computing majors and minors being experienced by so many universities.
Yesterday, via Uncertain Principles, I encountered Matthew Crawford's essay, Science Education and Liberal Education. Crawford writes beautifully on the essential role of science in the liberal education, the essential role of liberal education in democracy, and the vital importance of teaching science -- and presumably mathematics -- as worthy of study in their own right, independent of their utilitarian value to society in the form of technology. A significant portion of the essay catalogs the shortcomings of the typical high school physics textbook, with its pandering to application and cultural relevance. I shall not attempt to repeat the essay's content here. Go read it for yourself, and enjoy the prose of a person who both understands science and knows how to write with force.
Notwithstanding Crawford's apparent assertion that the pure sciences are noble and that computing is somehow base technology, I think that what he says about physics is equally true of computing. Perhaps our problem is that we in computer science too often allow our discipline to be presented merely as technology and not as an intellectual discipline of depth and beauty. As I've written before we need to share the thrill, that computing brings us -- not the minutia of programming or the features of the latest operating system or chip set. Surely, these things are important to us, but they are important to us because we already love computing for its depth and beauty.
Just yesterday, I commented abjectly in e-mail to a colleague that only twelve incoming freshmen had declared majors in computing during this summer's orientation sessions at our university. He wrote back:
I think we need to move away from presenting the CS major as a path to being a software drone in competition with India. We need to present it as leading edge, discovery based -- that is -- a science. I think too many students now see it as a software engineering nightmare -- a 40 year career of carefully punctuated cookbook code. Too boring for words.
Perhaps it is time for us to shift our mode of thought in computer science education toward the model of liberal education a lá the sciences. We might find that the number of students interested in the discipline will rise if we proudly teach computing as an intellectual discipline. In any case, I suspect that the level of interest and commitment of the students who do study computing will rise when we challenge them and address their need to do something intellectually worthwhile with their time and energy.
Merlin Mann says this about running and running shoes:
My concern is that there's a big difference between buying new running shoes and actually hitting the road every morning. Big difference. One is really fun and relaxing while the other requires a lot of hard work, diligence, and sacrifice.
He is so right. Have you bought running shoes lately? Ten or so manufacturers. Ten or so models per manufacturer. Prices into the $100s for an increasing number of models. Going for a run each morning is much easier.
Oh wait, that's not what he meant. So I disagree with his analogy after all. But I do agree with the real point of his essay, which is better expressed in this analogy:
You can buy a successively more costly and high-quality series of claw hammers until you've reached the top of the line, but until you learn how to use them skillfully, you're going to keep making ugly bird houses.
We can easily be so caught up in the excitement and fun of tinkering with new tools that we never getting any real work done. This separates the contenders from the pretenders in every area of life. It is true of productivity tool contenders and pretenders. It is true of runners and non-runners. It is also true of programmers and the folks who would rather tinker with their bash set-up and their .emacs file than actually cut code.
We all know people like this. Heck, most of us are people like this, at least some of the time in some parts of their lives. Starting -- even finishing -- is much easier than living in Ordinary Time. But that's where life is.
Some people run as a means to an end -- to lose weight, to "get in shape", to meet cute girls. For them, running may remain onerous forever, because it's just a chore aimed at reaching an external goal. Some people run for the sake of running. For them, getting up most mornings, pulling on the shoes, and hitting the road are a joy, not a chore. They are a part of the good life.
The same is true of productivity tool contenders and pretenders. When playing with the latest tool is more fun than getting things done, the mind and heart are in the wrong place. The same is true of programmers and tinkerers. When playing with Linux and .vimrc are more fun than writing programs, being a programmer isn't really for you.
When we find ourselves drifting into tinkerdom, sometimes all we need is to work on our habits. We really do want to write code, run five miles, get things done. But the distractions of the world have become a part of our routine and need to be put aside. Changing habits is hard...
As for the running versus running shoes analogy, I really do find choosing running shoes more stressful than it could be. Going into a shoe store or browsing through a running shoe catalog is like going to K-Mart and stepping into the shampoo aisle -- instant product overload. New Balance, Asics, Saucony, Nike, Brooks, Mizuno, .... Stability shoes, motion control shoes, racing flats, .... I just want a pair of shoes! I do my best to avoid all the indecision by sticking with the shoe that has served me well in the past, New Balance 766. Even still, that model number seems to change every year or two... (When my local shoe store stopped carrying 766s, I bought a couple of pairs of Asics GT-2099s that worked out pretty well.)
Now that I have the habit, running is relatively easy, fun and relaxing. I miss it on my off-day.
Merlin closes with sound advice for choosing tools and changing habits:
Making improvements means change and often pain along the way. It's hard to get better, and good tools like these can definitely ease the journey. I guess I'm proposing you try to understand yourself at least as well as the widget you're hoping will turn things around.
When you know yourself better, you will know your motivation better. That makes choices easier, sometimes obvious.
I am reminded of a conversation from October 2003, when I ran my first marathon. Several of us her in town were going to run Chicago as a team, which was more symbolic than practical -- we were all at different levels and speeds, so we'd run the race itself solo. One of our group had dropped out of training a month earlier. At a party, three of us were chatting about our training when the guy who had dropped out said that, while he had wanted to do the marathon, he just didn't have time to train -- work and family and outside activities and nagging little injuries had pulled him away.
After this guy left the conversation, the third guy -- our most experienced runner -- turned to me and said, "If you want to run..." He paused almost imperceptibly. "You run."
I took great comfort in that. I was still a relative beginner, and that statement stayed in my mind for all those days when I might wonder what I wanted to do. Maybe I should go buy a new pair of running shoes... No, let's just hit the road.
Busy, busy, busy.
As I mentioned in my anniversary post, the more interesting thoughts I have, the more I tend to blog. The last few weeks have been more about the clutter of meetings and preparing for some new tasks than about interesting thoughts. That's a little sad, but true. I did manage to spend a little more time at home with my wife this week, while my daughters were away at camp. That isn't sad at all.
I have been working a bit on the Educators' Symposium for OOPSLA 2005. My program committee and I are working on a panel session to close the symposium, one that we hope will spark the minds of attendees as they head out into the conference proper. The rough theme draws on what some of us see as a sea change in computing. Without a corresponding change in CS education, we may doom ourselves to a future in which biologists, economists, chemists, political scientists, and most everyone else teach courses that involve computers and modeling and simulation -- and we will teach only theory and perceived esoterica to a small but hardy minority of students. Maybe that is where CS education should go, but if so I'd rather go there because we intend to, not because we all behave as if we were Chance the Gardener from Being There. During our discussion of this panel, members of my program committee directed me to two classics I had not read in a while, Edsger Dijkstra's On the Cruelty of Really Teaching Computer Science and Tony Hoare's 1980 Turing Award lecture, The Emperor's Old Clothes. Reading these gems again will likely get my mind moving.
An unusual note regarding the Educators' Symposium... For many years now, OOPSLA's primary sponsor -- ACM's Special Interest Group on Programming Languages -- has offered scholarships for educators to attend the conference and the Educators' Symposium. A few years ago, when OOP was especially hot, the symposium offered in the neighborhood of fifty scholarships, and the number of applicants was larger. This year, we have received only nineteen applications for scholarships. Is OOP now so mainstream that educators don't feel they need to learn any more about it or how to teach it? Did I not advertise the availability of scholarships widely enough? As an OOP educator with some experience, I can honestly say that I have a lot yet to learn about OOP and how to teach it effectively. I think we are only scratching the surface of what is possible. I wonder why more educators haven't taken advantage of the opportunity to apply for a great deal to come to OOPSLA. If nothing else, a few days in San Diego is worth the time of applying!
I have had my opportunity to encounter some interesting CS thoughts the last few weeks, through meetings with grad students. But I've had a couple of weeks off from those as well. Maybe that's just as well... my mind may have been wandering a bit. Perhaps that would explain why one of my M.S. students sent me this comic:
I've recently run across in several different places recommendations for Leonard Koren's Wabi-Sabi: for Artists, Designers, Poets & Philosophers, so I thought I'd give it a read. My local libraries don't have it, so I'm still waiting. While looking, though, I saw another book by Koren, called 13 Books : (Notes on the Design, Construction & Marketing of my Last...). The title was intriguing, so I looked for it in the stacks. The back cover kept my attention, so I decided to read it this weekend. It contained the opening sentences of the book:
Authorship unavoidably implies a certain degree of expertise about the subject you are writing on. This has always troubled me because, although I have written numerous books on various subjects, I've never really considered myself an expert about anything. Recently, however, I had an encouraging realization. Surely I must know more about the making of the 13 books
... that he has written than anyone else! So he wrote this book, which consists of a discussion of each of his previous works, including his source of inspiration for the work, the greatest difficulty he faced in producing it, and one enduring lesson he learned from the experience.
(This book ties back nicely to two previous entries here. First, it adds to my league-leading total for being the first reader of a book in my university library. Second, it was a gift to the library by Roy Behrens, a design professor here whose Ballast Quarterly Review I mentioned a few months ago.)
13 Books is clearly the product of a graphic designer who likes to explore the interplay between text and graphic elements and who likes to make atypical books. It's laid out in a style that may distract some readers. But, within the self-referential narrative, I found some of Koren's insights to be valuable beyond his experience, in terms of software, creativity, and writing.
Projects ultimately develop their own identity, at which point the creator has a limited role in determining its shape. Koren learned this when he felt compelled to include a person in one of his books, despite the fact that he didn't like the guy, because it was essential to the integrity of the project. I feel something similar when writing programs in a test-code-refactor rhythm. Whether I like a particular class or construct, sometimes I'm compelled to create or retain it. The code is telling me something about its own identity.
Just from its brief appearance in this book, I can see how the idea of wabi-sabi found an eager audience with software developers and especially XPers. Koren defines wabi-sabi as "a beauty of things imperfect, impermanent, and incomplete... a beauty of things modest and humble..." In the face of changing requirements and user preferences, we must recognize that our software is ever-changing. If our sense of beauty is bound up in its final state, then we are destined to design software in a way that aims at a perfect end -- only to see the code break down when the world around it changes. We need a more dynamic sense of beauty, one that recognizes beauty in the work-in-progress, in the system that needs a few more features to be truly useful, in the program whose refactoring is part of its essence.
Later in the book, Koren laments that making paper books is "retrograde" to his tech friends. He then says, "And the concept of wabi-sabi, the stated antithesis of digital this and digital that, was, by extrapolation, of negligible cultural relevance." I see no reason that wabi-sabi stands in opposition to digital creations. I sense it my programs.
Finally, here is my favorite quote from the book that is unwittingly about software:
The problem with bad craftsmanship is that it needlessly distracts from the purity of your communication; it draws away energy and attention; it raises questions in the reader's mind that shouldn't be there.
Koren writes of font, layout, covers, and bindings. But he could just as easily be writing of variable names, the indentation of code, comments, ...
On creativity and learning
At least one of the thirteen books was inspired by Koren's rummaging through his old files, aimlessly looking at photos. We've seen this advice before, even more compellingly, in Twyla Tharp's "start with a box". (That reminds me: I've been meaning to write up a more complete essay on that book...)
Taking on projects for reasons of perceived marketability or laziness may sometimes make sense, but not if your goal is to learn:
The ideas for both books came too quickly and easily, and there was no subsequent concept of development. In my future books I would need to challenge myself more.
In building software systems, in learning new languages, in adopting new techniques -- the challenge is where you grow.
In retrospect, Koren categorized his sources of inspiration for his books. The split is instructive: 40% were the next obvious step in a process, 30% came from hard work, and 30% were the result of "epiphanies from out of the blue". This means that fully two-thirds of his books resulted from the work of of being a creator, not from a lightning bolt. Relying on flashes of inspiration is a recipe for slow progress -- probably no progress at all, because I believe that those flashes ultimately flow from the mind made ready by work.
On writing and publishing
Koren is a graphic designer for whom books are the preferred medium. Throughout his career, he has often been dissatisfied with power imbalance between creators and publishers. He is constantly on the look-out for a new way to publish. For many, the web has opened new avenues for publishing books, articles, and software with little or no interference from a publisher. The real-time connectedness of the web has even made possible new modes of publication such as the blog, with conversations as a medium for creating and sharing ideas in a way. Blogs are often characterized as being ephemeral and light, but I think that we'll all be referring to Martin Fowler's essays and the Pragmatic Programmers' articles on their blogs for years to come.
While Koren may remain a bookmaker, and despite his comments against digital technology as creative medium, I think his jangling, cross-linked, quick-hit style would play well in a web site. It might be interesting to see him produce an on-line work that marries the two. Heck, it's been been done with PowerPoint.
As someone who has been reflecting a year writing this blog, I certainly recognize the truth in this statement:
A book need be grand neither in scale nor subject matter to find an audience.
Waiting until I have something grand to say is a sure way to paralyze myself.
Finally, Koren offered this as the enduring lesson he learned in producing his book Useful Ideas from Japan:
Reducing topical information to abbreviated humorous tidbits is a road to popular cultural resonance.
It seems that Koren has the spirit of a blogger after all.
A couple of quotes about thinking big -- one serious, and one just perfect for the end of a Friday:
Think Global, Act Local
Grady Booch writes about the much-talked-about 125 hard questions that science faces, posed by the American Association for the Advancement of Science on the occasion of its 125th anniversary:
Science advances daily through the cumulative efforts of millions of individuals who investigate the edges of existing knowledge, but these sort of questions help direct the global trajectory of all that local work.
At the end of his entry, Grady asks a great question: What are the grand challenges facing us in computer science and software development, the equivalent of Hilbert's problems in mathematics?
When Is Enough Enough?
Elizabeth Keogh writes about reality for many readers:
If you think you're going to finish reading all those books you bought, you need more books.
I'm a book borrower more than a book buyer, but if I substitute "borrowed" for "bought", this quote fits me. Every time I read a book, I seem to check out three more from the library. I recently finished Glenway Wescott's "The Pilgrim Hawk", and I'm about to finish James Surowiecki's "The Wisdom of Crowds". Next up: Leoneard Koren's "13 Books". (I'm a slow reader and can't keep up with all the recommendations I receive from friends and colleagues and blogs and ...!)
While out running today, I had one of those flashes of inspiration -- a crystal-clear, wholly-formed thought -- for how I might introduce agile software development in an undergraduate course. In this image, we begin the first day of a course with a software project to implement. The first thing we do is work as a group to decompose the into chunks that the students believe they can implement in one day. No Planning Game jargon; just a bunch of students working with me to design the course project and the programming assignments they will have to do. On another day, we could work on one of the day-long projects, breaking it down further and writing a test for each small piece before we write any code. No TDD or JUnit jargon; just a bunch of folks writing short test programs for code they think they understand how to write.
I'm not sure why this flash happened today. I'm not slated to teach agile software development per se for a while. The last time I taught the offers some reason that my mind would seek a new way to open the course. Then, I *talked about* agile development first, and we began to work on agile practices with test-first development first. At the end of the course, I felt as if too few of the students had grokked the idea, at least in part before they never felt motivated to give it a reasonable shot. I don't mean that the students necessarily started with a desire not to get it; rather, they never felt a strong internal desire to endure the pain of changing their habits for building software. And old habits die hard, if at all.
This feeling brings to mind something I read a couple of weeks ago:
People don't choose rationally to listen to your message and then have a feeling about it. They choose to listen to your message because they have a feeling about it.
University instructors and industrial trainers should keep this thought close to their minds. The folks at Creating Passionate Users know that it is hard to spark passion in readers or product users when they have no particular feeling for the work. The same is true for many students in a course. I may be able to draw in a few students slowly over time, as things click in their minds, but for most I need to help them want to learn and know and do. This is especially true of helping people to change deeply ingrained habits,such as how they develop software.
Then what should I read today but this quote from Malcolm Gladwell's The Tipping Point, over at Agile Advice, presented in just the context of my inspirational moment:
...the content of the message matters, too. And the specific quality that a message needs to be successful is the quality of "stickiness." Is the message - or the food, or the movie, or the product - memorable? Is it so memorable, in fact, that it can create change, that it can spur someone to action?
I need to find and communicate better the stickiness of agile development. My running thought seems closer to agile development's stickiness than what I've done before.
If my thoughts were controlled more by my rational side, I would be having flashes of inspiration for teaching my programming languages course this fall. What is the stickiness of functional programming, of Scheme? How can I shape a mindset in my students whereby they feel passion to learn these new ideas and change how they think about programs?
Maybe I need to go for another run and cross my fingers.
One of the things I miss being at a smaller school in a less densely populated part of the country is the ability to go to stimulating research talks on a regular basis. When I was at Michigan State, I could go to a good talk in computer science or a closely related discipline frequently, if I had the time and inclination. It's hard to create that sort of environment at a school the size of UNI. One of my goals for the department this fall is to create a seminar series that draws on the research our faculty is doing, as well as research and scholarship being done at the many other schools in Northeast Iowa. I don't know if we have a critical mass of audience to sustain such a series, but I think that it's worth finding out.
In the meantime, following other people's involvement in research talks is one solace. Andrew Birkett recently wrote about attending the Scottish Programming Languages Seminar held last month. Just reading his summary stimulated my mind a bit...
One talk described an attempt to measure the productivity difference between static and dynamic languages, toward which Andrew was skeptical. I am, too. The difference between static and dynamic languages is at least as much one of culture and habit of thought as it is of language and tools.
When you use a dynamic language, it's not because you have a masochistic enjoyment of finding statically-findable bugs by hand. It's because you enjoy a much more flexible overall programming experience - different toolset, and better support for "exploratory programming" as you learn about the problem domain.
Measuring differences in productivity across cultures is tricky. In my experience, folks just end up scratching their heads at the other camp and thinking, "But that's not even a part of my universe." That said, I would be interested in evaluating an attempt to tackle this hard problem.
Another talk centered on the notion that the purpose of type checking is, at one level, to distinguish 'good' programs from 'bad' ones, for a particular definition of those evaluative terms. In the usual sense of static typing, good programs pass the type checker, and bad programs do not. The presumption of strongly, statically typed languages is that the first step toward being a good program is passing the type checker. This presumption can get in the way sometimes. I remember my frustration when learning Haskell: I would write a mutually recursive function that executed correctly for all inputs, but the Haskell type inference system refused to accept the definition because it could not infer the types of the inductive data elements. Writing those type definitions by hand proved difficult or impossible.
(Don't take this remark about Haskell out of context, though. It is a very cool language that can change how you think about programs -- definitely worth the energy to go learn it!)
Defining 'good' and 'bad' programs in terms of passing a type checker is potentially a very fine thing to do, but it has important implications for how programmers think about programs and programming. What if we decided that the first step toward being a good program was something else and then designed a tool to enforce that notion? Programming might be quite different! In a sense, I think that test-driven development is an example of just this sort of thing. Passing a test is more important than making the type checker happy. Working in dynamic languages such as Scheme can feel that way, too -- the emphasis is not on types but on passing test cases.
The talk that raised this idea about type systems went on to describe an interesting idea: creating a type checker that blends static and dynamic checks. The checker infers as much as it can statically and then leaves the rest of the type checks for run time.
And then you can either go back and tweak your source code to provide more information, or you can go ahead and run your program, knowing that some properties have been checked statically (i.e., they are true for all possible runs of the program) and some will be checked dynamically (i.e., the program will terminate if a properties is discovered to be false).
If Haskell had this sort of flexibility in its typing system, then I would have been more inclined to use the language as more than a learning and research vehicle.
Now that I have mentioned Haskell a couple of times, I will close with one last comment from Andrew, about another of the talks at the seminar:
The formal side of this talk was a little bit beyond me. I have to concentrate when people discuss Monads formally.
I have to admit, with some sheepishness, that reading papers and listening to talks about monads have always made my head hurt. I don't know if this situation can be remedied by the right sort of practice, or if it is merely a sign of my fundamental cognitive limitations. In either case, I'm content with my state for now.
Why do you never find anything written about that
idiosyncratic thought you advert to, about your
fascination with something no one else understands?
Because it is up to you.
-- Annie Dillard, "The Writing Life"
Today is the one-year anniversary of Knowing and Doing. When I first started, I was not certain that I had anything to say, at least anything that anyone with a real life would want to take time out from their lives to read. I decided, though, that the writing would be its own reward; that, in taking the time to put words to the thoughts in my head, I would have better, more complete thoughts.
So I wrote. I wrote down thoughts I had as I read interesting books, as I chaired conferences, as I wrote programs, as I taught classes, and as I ran. Somehow, they seemed worth writing down to me.
My 100th post came on November 20. My 200th post came in the midst of agile moments on May 31. There is little doubt that my most-read post so far has been this report on Alan Kay's talks at OOPSLA 2004. I've seen it referenced and linked to more often than any other article I wrote; I received more individual e-mail responses to it than any other as well.
That article is a great example of what blogs can do for both the writer and the world of readers. Alan's talks inspired me, and I wanted record the source of that inspiration for my own long-term benefit. So I blogged it. Writing it all down and organization a coherent report enriched my own experience. But by blogging it, I helped share a small part of the experience with many folks who were unable to come to OOPSLA and hear the talks for themselves. I only hope that my article helped Alan to inspire some of those readers, who found my article as regular readers of Knowing and Doing, or who stumbled upon it via a Google search. It is important to put Alan's ideas before as many people as possible, so that they will find a home in the minds that can make his vision a reality. Perhaps someday, I will be one of the folks who helps to make Alan's vision reality, but perhaps I have an even greater chance of affecting the world by writing about what I see, hear, and learn, and helping greater minds than mine run with ideas.
When I first starting writing my blog, I asked a net acquaintance who blogs how to get people to read my stuff. What a lame question that was. It turns out that there isn't much of a recipe for creating readership other than "write stuff people want to read". I just started writing, and a small readership, word of mouth, and Google did the rest. I don't have any idea how many people read my blog regularly, because I've never tried to capture that data, or retrieve it from web server logs. I do know that I receive occasional e-mail from folks who have read an article and taken the extra initiative to drop me a line. I'm surprised by how good that feels, even today.
The best way to write stuff people want to read is to write stuff that matters to you. If an idea matters to you, then it matters. Getting over the fear that no one will care frees you to get down to work.
Jorn Barger, considered by some the coiner of the term 'weblog', once wrote, "The more interesting your life becomes, the less you post... and vice versa." Perhaps he was talking about the sort of blog that only reports the daily trivia of life, in which case more blogging reflects more triviality. But my experience as a blogger is just the opposite: the more interesting thoughts I have, the more I blog. I write more when I am reading good books, going to good conferences, discussing provocative ideas with smart friends and colleagues, and doing challenging work. The times I am blocked or uninspired are the times when I am not doing much interesting in my life. In that sense, Knowing and Doing serves as a barometer for the quality of my own intellectual experiences. When the mercury drops too low, I need to shake things up. Sometimes, it's as simple as taking friends' advice to read a couple of old articles (  and ) and seeing what a master has to teach me today.
Upon which I reminded myself that on the whole,
throughout life as a whole, the appetites which
do not arise until we have resolved to eat,
which cannot be comprehended until we have eaten,
are the noblest....
-- Glenway Wescott, "The Pilgrim Hawk"
Last July 9, I said, Welcome to my blog. This July 9, I say "Thank you". Let's see what a second year of Knowing and Doing will be.
Daring Fireball recently ran a piece on several issues in the Apple world, including the recent streamlining of the iPod line:
This emphasis on a simplified product lineup has been a hallmark of the Jobs 2.0 Administration. For the most part, given a budget and a use case, it's pretty easy to decide which Mac or which iPod to buy. (The hardest call to make, in my opinion, is between the iBooks and 12" PowerBook.)
I agree with John's assessment of the last tough choice -- I recently agonized over the iBook versus PowerBook choice, focusing for budget reasons on the crossover point from iBook to PowerBook. In the end, I think it was more pride than anything else keeping me on the fence. I love my old G3 clamshell PowerBook and like the look of the titanium Powerbooks. But given my real needs and budget, the iBook was the right choice. One potential benefit of going with the simpler, lower-cost alternative for now is that it postpones a more substantial purchase until the shift to Intel-based processors is complete. My next PowerBook can be one from The Next Generation.
My new iBook arrived last week. I've been having great fun playing with OS X 10.4... My old Powerbook is still running Jaguar, so I have been missing out on the many cool things available only on Panther. I'm only just now scratching the surface of Dashboard and Expose and the like, but they feel great. My only minor regret at this point is going with the 30GB drive. I'm already down to 13 gig free, and I haven't done much more than basic set up and my basic set of apps. In reality, that's still plenty of space for me. I don't store lots of video and music on my laptop yet, and my data will fit comfortably in 10 gig. If I do need more space, I can just pick up a external drive.
While setting up this machine, it really struck how much of my Mac experience now is bundled up with Unix. In the old days, I set up Macs by dragging StuffIt archives around and creating folders; I spent a few minutes with control panels, but not all that much. Setting up OS X, I spend almost all of my time in a terminal shell, with occasional forays out to System Preferences. This machine switch may be more Unix-heavy than usual, because I've decided to follow OS X from tcsh to bash. Rewriting config files and hacking scripts is fun but time consuming.
Of course, this change pales next to the switch I made when I went to grad school. As an undergrad, I became a rather accomplished VMS hacker on an old cluster of DEC Vaxes. When I got to my graduate program, there wasn't a Vax to be seen. Windows machines were everywhere, but the main currency was Unix, so I set out to master it.
Another thing that struck me this week is how much of my on-line identity is bundled up in my Unix username. "I am wallingf." That has been my username since my first Unix account in the fall of 1986, and I've kept it on all subsequent Unix machines and whenever possible elsewhere. At least I know I'm not the only one who feels this way. Last year as we prepared for the Extravagria workshop at OOPSLA 2004, Dick Gabriel wrote that rpg is the
Login name for RichardGabriel. I have used this login since 1973 and resent ISPs and organizations that don't allow me to use it.
Anyway, my iBook now knows me as wallingf. I guess I should give her a name, too.
Do you remember this old Billy Crystal/Christopher Guest skit from Saturday Night Live? The guys were janitors. When they ran into one another, they would take turns describing to one another accidents that had happened to them. The first incidents in the exchange were the sort that could happen to a working guy, such as "You know when you're working in the shop and you hit your thumb with a hammer?" But as the skit progresses, the accidents become incidents of strange, self-inflicted pain that could never happen accidentally, such as "You know when stick your inside your car door and just slam the door right on your head? That really hurts." The unforgettable catch phrase of the skit was this classic: "I *hate* when that happens."
Interval training on a track can be like that. I imagine most non-runners listening to me tell tales of my track work-outs and thinking of me the way we all thought of Guest and Crystal at the end of their skits. "I *hate* when that happens." Well, duh. It's all quite funny, unless your the guy with his head crushed by the car door.
When I run intervals, or repeats, I am trying to work my body at the edge of its capabilities. As a result, there is little margin for error or unexpectedness. When things don't go as well as expected, the workout can feel something like slamming a car door on my head -- voluntarily, at 5:30 or 6:00 in the morning. I hate when that happens.
Doing my 6x1200m workout this morning, I re-learned what all good experimental scientists know: too many free variables make it difficult to know why what happened happened when what happened isn't what you expected.
What happened? I came up way short today. I was trying to run each repeat in 4:52 or less. The first was tough but right on mark. The second slowed down by 3 seconds and felt bad enough that I decided to jog lightly through the third. When I ran the fourth, I slowed down another 2 seconds and realized that I was going to be able to meet my goal for the day. In place of the fifth and sixth repeats, I chose to alternate faster laps with slower ones, in hopes of not turning the day into just another slow jog.
But why did this happen? Here are some possibilities:
Running outside itself wasn't likely the problem, though the nature of the feedback is different. Attempting six repeats wasn't likely the problem, either, because the problem wasn't with Repeat 6; it was Repeat 3, or even #2.
I think the most likely explanation is the combination of three variables. First, my legs are still tired from last week. Second, I tried running 400m recoveries instead of the more ordinary 600m (50% of the repeat distance). I will try to remedy those next week.
Finally, and perhaps most important, I now realize that I was running repeats longer than 1200m. Last week's 4:53 repeats were right at my target distance, because I was running to lane markers on the indoor track. This morning, I was running three laps in Lane 4 of the 400m outdoor track. Four laps in Lane 4 is actually about 1.05 miles, so my three laps work out as a little over 1266m. That extra 66m is enormous when it comes to running at my limits. To do my target 1200m pace, I should have allowed myself an extra 16 seconds on each repeat!
The idea that my laps were longer than planned didn't occur to me at all until I was out on the track, slogging through laps, asking myself, "But why?" I *hate* when that happens.
I should have taken the feedback from my body at face value and adapted my pace. Whatever the reason, I was not going to be able to do 1:37 laps, so I should have eased off to a pace that I could sustain. Instead, I despaired a bit and gave up on a couple of the repeats. Note to self: Feedback is good; use it to get better.
Multiply these three factors together, and you get a workout that does not go as planned.
Then again, in retrospect, maybe my times weren't so bad after all. After crunching the numbers, I think that I can safely conclude that I was simply trying to run too fast.
Unfortunately, things don't usually turn out so tidily. Ordinarily, I wouldn't know for certain the reason that the workout that did not go as planned, because I put too many variables into play. What I don't want to do is use my good fortune this week as rationalization for making the same mistake next week.
My excuse, er, reason, for changing so many things at once is that training time is precious. From last Sunday, I had exactly 13 weeks until the Twin Cities Marathon. If I hope to meet my race goals, I need to make steady and rapid progress in my workouts.
That is just the sort of reason that we software developers use to convince ourselves and our clients that we need to shove more and more features into the next release. It's the same excuse that teachers tell themselves and their students when they try to squeeze just one more topic into the already crowded syllabus of a course. The results are similar, too. The developers and instructors often fail to achieve their goals; software clients and students are left holding the bag. And then in the end, we are left asking ourselves why.
Of course, this morning's experience also taught me another lesson: do my homework better when it comes to computing repeat distances on the track. "Do your homework" is, of course, also a fine piece of advice for software developers, software clients, teachers, and students alike. :-)
A week or so ago, I ran across Adam Connor's blog entry What do we know about teaching programming skills?. I wanted to respond immediately, either in a comment there or in a more complete essay here. But then I realized: I don't have anything succinct to say. As much as I think about teaching programming, and discuss it with friends, and write about facets of it here, I don't have a broadside that I can offer to folks like Adam who seek a concise, straightforward introduction to what we know about teaching programming. This realization disappointed me.
For now, I can offer only a few points that seem to be recurring themes in how I understand how to teach programming. Later I will write up something that Adam and people in his position can use right away. Whether that will be in time to help Adam much, I don't know...
In no particular order:
That's a start. You know what they say: start small, then grow.
The beginning of the Tour de France on Saturday reminded me of this diary entry by Santiago Botero, a Colombian rider in cycling's Tour de France, the most grueling of athletic events.
There I am all alone with my bike. I know of only two riders ahead of me as I near the end of the second climb on what most riders consider the third worst mountain stage in the Tour. I say 'most riders' because I do not fear mountains. After all, our country is nothing but mountains. I train year-round in the mountains. I am the national champion from a country that is nothing but mountains. I trail only my teammate, Fernando Escartin, and a Swiss rider. Pantani, one of my rival climbers, and the Gringo Armstrong are in the Peleton about five minutes behind me. I am climbing on such a steep portion of the mountain that if I were to stop pedaling, I will fall backward. Even for a world class climber, this is a painful and slow process. I am in my upright position pedaling at a steady pace, willing myself to finish this climb so I can conserve my energy for the final climb of the day. The Kelme team leader radios to me that the Gringo has left the Peleton by himself and that they can no longer see him.
I recall thinking 'the Gringo cannot catch me by himself'. A short while later, I hear the gears on another bicycle. Within seconds, the Gringo is next to me - riding in the seated position, smiling at me. He was only next to me for a few seconds and he said nothing - he only smiled and then proceeded up the mountain as if he were pedaling downhill. For the next several minutes, I could only think of one thing - his smile. His smile told me everything. I kept thinking that surely he is in as much agony as me, perhaps he was standing and struggling up the mountain as I was and he only sat down to pass me and discourage me. He has to be playing games with me.
Not possible. The truth is that his smile said everything that his lips did not. His smile said to me, 'I was training while you were sleeping, Santiago'. It also said, 'I won this tour four months ago, while you were deciding what bike frame to use in the Tour. I trained harder than you did, Santiago. I don't know if I am better than you, but I have outworked you and right now, you cannot do anything about it. Enjoy your ride, Santiago. See you in Paris.'
Obviously, the Gringo did not state any of this. But his smile did dispel a bad rumor among the riders on the tour. The rumor that surfaced as we began the Prologue several days ago told us that the Gringo had gotten soft. His wife had given birth to his first child and he had won the most difficult race in the world - he had no desire to race, to win. I imagine that his smile turned to laughter once he was far enough not to embarrass me. The Gringo has class, but he heard the rumors - he will probably laugh all the way to Paris. He is a great champion and I must train harder. I am not content to be a great climber, I want to be the best.
I learned much from the Gringo in the mountains. I will never forget the helpless feeling I had yesterday. If I ever become an international champion, I will always remember the lesson the Gringo taught me.
Botero wrote that entry back in 2000, the year after Armstrong won his first Tour. He went on to win that Tour as well, on his way to a record six in a row. This year, Armstrong rides his last Tour de France, seeking to retire as a champion yet again. By all accounts, he still feels the fire to win. More important, he felt the fire to prepare to win all winter and spring.
Botero finished sixth in the 2000 Tour. He is racing this year's Tour, too, and his recent win at Romandie signals that he may have what it takes to challenge again for the title in France.
Botero learned what separates himself from Armstrong from the master himself. The will to prepare to win comes from within, and sometimes it's hard to appreciate until you see its power first hand. Even then, achieving excellence exacts a heavy commitment. How much do you want it?