My recent entry on student evaluations brought to mind a few other items on not reading that I've encountered recently.
Having a good memory is a serious impediment to understanding. It lets you cheat your way through life.
So, Montaigne and I need not worry. Had we better better memories, we might be skating through life as easily as Yegge.
I hope it's clear that at least this last example is not serious at all.
In March I talked about a couple of OOPSLA submissions written by our merged ChiliPLoP groups. In May I wrote about the verdict on one but forgot to mention the other. Maybe because the rejection was so much more interesting!
Anyone, our second submission was accepted into the Educators' Symposium. It is not a paper, really, but an extended abstract for an activity we will run: a code review recast as it might happen in a software studio. We hope to give participants a snapshot of what a studio-based course looks, feels, and works like. This is something instructors can try on a small scale in class and, if it works for them, expand throughout their course. Even if code reviews is all the farther they go, we co-authors think that this will be a useful step for many instructors. It draws on experiences in the writers' workshops of PLoP helps students to think about the many design choices they make when writing software, and to make them reflectively rather than subconsciously.
The real trick to this activity will be the homework we give before the symposium:
Before coming to OOPSLA, Educators' Symposium participants will be asked to submit a program, in a language of their choice (though using only standard libraries), which implements the core of a program to generate Tag Clouds from a data set. ...
My experience with many workshops in the past and especially with the Educators' Symposium is that participants never do this kind of homework. Some are well-intentioned but never make time for it, while others figure they can skate by without having written the code. (Sounds as if professors are a lot like their students, huh?) Without code to review, a code review doesn't get very far. We hope that we can find a way to encourage symposium attendees to overcome history and come with some code to workshop.
I received my copy of the student evaluations from my spring course, which was really three courses that felt like one to me and a few common students. One of the open-ended questions on the form my university uses asks the student to complete this blank:
I could have improved my learning in this course by _____.
After teaching for a while now, I can predict what students will say in this section. This semester was a perfect example.
The second most common answer is a variation of ...
reading the textbook
It doesn't what book I assign; how big it is; whether it is mostly exposition or mostly code; or whether it's written in an academic style or in the vernacular. A few students read the book, and a few of those will typically praise it, but most don't read much if any of it.
The most common answer is a variation of (drumroll, please) ...
starting the homework assignments sooner
Sooner, so they had more time to work on them. Sooner, so that they could ask questions when they were stumped. Sooner for all sorts of reason, but always sooner.
Neither of these bits of wisdom are new to them. If nothing else, they have heard me exhort them to start sooner and to read more. I suppose I could do more to encourage these behaviors, such as giving quick quizzes every day over the reading, but most strategies feel wrong. Do either students or I really want to turn the class into a treadmill of points for their grade? Do I want to have to grade all that stuff? Aren't they adults?
For homework assignments, one thing we instructors can do to encourage beginning sooner is to have short iterations with frequent submission. In my spring course, I had small programming exercises due weekly. I could have tried biweekly submissions, or a problem every other day. But that feels like micromanagement to me. Students have other courses and work schedules to consider, and I like to give them at least a few days to navigate through their various duties. And besides, aren't they adults?
I don't think that students want to be micromanaged with quizzes and deadlines, and I do think think they genuinely mean well. Maybe the problem is that they view the comments they make on student evaluations as backward-looking, when instead they should think of them as forward-looking. Perhaps we should phrase the question as
I will improve my learning in future courses by _____.
The student's evaluation of the instructor would then be more like a retrospective that benefits the student as much as the instructor, because it asks both parties to consider how they can improve their results in the "next iteration" -- the next courses they take. These comments about the future, not the past.
(Ooh, it just occurred to me: perhaps I could try a brief something after one of the assignments early in the course that plays the role of retrospective. Maybe if students consciously consider the value of starting sooner and reading the text during the course they can change their behavior soon enough to affect their performance. This would create more frequent futures!)
What did I learn from these evaluations that will help me in the future? In every course, there is a set of common answers to the item "My learning in this course would have improved if the instructor had _____.", but for this item there are also usually an answer or two that stand out as particularly salient or which teach me something new.
From this course, students reminded me of the value in reviewing solutions to homework assignments soon after they submit their solutions. This is always a valuable tactic, and especially in a course where students are learning new languages and styles of programming. The best way to learn is to see different solutions, including ones that demonstrate idiomatic usage. It gives students a way to compare their solutions and to learn from differences. I let the fact that most of students this semester were juniors and seniors with a fair amount of programming experience convince myself that maybe we could get by without this sort of follow-up. But that was probably just a juicy rationalization that allowed me to "squeeze in more material", to the detriment of my student's learning.
I have written about that before in my blog. This entry is now an example of how I am sometimes no better than my students at practicing what I recommend in a retrospective! Let's see if I can do better at this in the fall.
The rest of my evaluation data was pretty good -- a nice ego boost in a week where I needed one. Consider this an open "thank you" to the students who take time to write both suggestions for improvement and positive comments that let me know that, on the whole, they like my courses. Those positive comments help keep us instructors motivated just as much as positive feedback helps students feel better about hanging in there.
I have been home alone with my daughters for the last few days. It's always neat to have the chance to talk with the girls over an extended time, because they do say some amazing things.
Over lunch a few days ago, we were talking about classes at school. I had been telling them about Lockhart's Lament, which I had just started reading. (More on that later.) Our conversation turned to art class, and how some teachers don't seem to understand what it means to create art. One teacher always told the students to keep things simple, because then they would get done faster. My younger daughter couldn't hide her exasperation. "She doesn't understand. It's not about fastest; it's about masterpieces." That bit of wisdom reminded me why I know she will do good things in her life.
My puffed-up pride didn't last long. The next day, in the course of a conversation I've already forgotten otherwise, she told me, "It's not that you're old, Dad; you're just too old." That's too much truth for me.
Sometimes the girls like my relatively advanced age. Over the weekend, they pulled my old Trivial Pursuit game off the shelf, and we had several hours of fun. I love that they've already read enough in their short lives to be able to play the game pretty well, and that they enjoy spending an evening or two trading questions and answers with their old dad.
I've long been a fan of William James, and once wrote briefly about the connection between James's pragmatism and my doctoral work on knowledge-based systems. I was delighted yesterday to run across this quote from James's The Principles of Psychology, courtesy of 43 Folders and Linda Stone:
[Attention] is the taking possession by the mind, in clear and vivid form, of one out of what seem several simultaneously possible objects or trains of thought. ... It implies withdrawal from some things in order to deal effectively with others....
Prone as I am to agile moments, this message from James struck me in an interesting way. First of all, I occasionally battle the issue that Stone writes about, the to-do list that grows no matter productive I seem to be on a given day. (And on lazy summer June days, well, all bets are off.) James tells me that part of my problem isn't a shortage of time, but a lack of will to focus. I need to make better, more conscious choices about what tasks to add to the list. Kent Beck is fond of saying something to the effect that you may have too many things to do and too little time, but you ultimately have control over only one side of the equation. James would tell us the same thing.
My mind also made a connection from this quote to the agile software and test-driven development practice of working on small stories, on taking small steps. If I pick up a card with a single, atomic, well-defined feature to be added to my program, I am able to focus. What is the shortest step I can take and make this feature part of my code? No distractions, no Zerstreutheit. Though I have an idea in mind toward where my program is evolving, for this moment I attend to one small feature and make it work. Focus. James would be proud.
I think it's ironic in a way that one of the more effective ways to reach the state of flow is to decompose a task into the smallest of tasks and focus on them one at a time. The mind gets into a rhythm of red bar-green bar: select task, write code, refactor, and soon it is deep in its own world. I would like to be more effective at doing this in my non-programming duties. Perhaps if I keep James and his quote in mind, I can be.
This idea applies for me in other areas, in particular in running and training for particular events. Focusing each day on a particular goal -- intervals, Long Slow Distance, hill strength, and so on -- helps the mind to push aside its concerns with other parts of the game and attend to a particular kind of improvement. There is a great sense of relaxation in running super-hard repeats when the problem I've been having is, say, picking up pace late in a run. (I'd love to run super-hard repeats again some day soon, but I'm not there yet.)
I saw a link to Wordle on Exploration Through Example and decided to try it out on Knowing and Doing. Wordle generates a tag cloud for any text you paste in. I pasted in the content of my blog since the beginning of 2008, and it produced this lovely image:
That looks like a pretty good capsule of what I've been writing about lately. I was a bit surprised at the size of "students", but I probably shouldn't have been. "Programming", "work", "time", "ideas", "read", and "computer"/"CS"/"computing" hit the mark.
Besides, I had fun writing the script to pull plain text for my posts from their source form. It was a nice break from a day dealing with lab reservations and end-of-year budget issues.
I ran across a pattern today that reminded of another I encountered while at ChiliPLoP. Both help developers deal with side effects, changes to a program's state. Let me share these patterns with you all, with a common explanation of their value.
Most programs written these days are in a style where setting and changing the values of one or more variables, via a sequence of imperative statements. Side effects are a common source of programmers' misunderstanding when reading code. A program can change a variable's state almost anywhere, and that makes reading any bit of code uneasy: "Do I really know what this variable means right now?" Using only local variables only in the context of a small procedure is one way to localize effects. Even still, problems can arise.
I won't try write full patterns for these. I'll write short patlets and give you links to the articles I read, which do a good job talking about the ideas.
Mutual Recursion with Side Effects
In Solving Every Sudoku Puzzle, Peter Norvig builds a Python program for the title task. About 40% of the way in, he says:
If you have two mutually-recursive functions that both alter the state of an object, try to move almost all the functionality into just one of the functions. Otherwise you will probably end up duplicating code.
Duplicate code is usually a bad thing, because it creates a problem for programmers keeping the copies in sync. Duplicate code that modifies state is especially bad, because it brings in the extra complication of making another procedure harder to understand.
Side Effects and Python's Default Parameters
Coincidentally, the second pattern involves Python, too. This time the pattern is Python-specific, addressing an issue with a language feature.
Context: You are writing a procedure with a default parameter.
Problem: The procedure needs to modify the default parameter. Python evaluates a default parameter's initial value only on the first call to the procedure.
Solution: Whenever the parameter is missing, initialize it within the method.
Tim Ottinger gives his implementation technique in Python's Mutable Default Problem:
def function( item, stuff=None ): stuff = stuff or  # ... modify stuff, etc.
This pattern allows the user to take advantage of the default parameter when he has no collection to send. It does so by following a principle laid out in the article Ottinger references: In Python, "don't use mutable objects as function defaults."
This pattern may not be Python-specific, because there may be other languages with this initialize-once behavior. It seems like a bug to me, not a feature, but I'm not a Python programmer and so can't speak authoritatively. But I am glad that Ruby doesn't do this.
Postscript: While preparing this article, I learned something new about Ruby, unrelated to this issue. It is possible to extract from a class a new class that has a subset of the original class's protocol. Very nice indeed!)
Here I am, sitting in the office on a quiet Friday afternoon, looking forward to the weekend and writing up a short blog entry on a couple of cool software patterns. In another window is playing the WWDC 2008 keynote talk.
Suddenly, my ears hear the soothing voice of Steve Jobs say:
Imagine you are a university professor and you are teaching a class in how to write iPhone apps.
Writing code. An iPhone. Teaching class. Sweet Dreams (are made of this).
Back to work.
In recent days, I have written about not reading books and the relationship of these ideas to writing, from my enjoyment of Pierre Bayard's How to Talk About Books You Haven't Read. A couple of readers have responded with comments about how important reading is. Don't worry -- much of what Bayard and I are saying here is a joke. But it is also true, when looked at with one's head held tilted just so, and that's part of what made the book interesting to me. For you software guys, think about Extreme Programming -- an idea taken to its limits, to see what the limits can teach us. You can be sure that I am not telling you not to read every line of every novel and short story by Kurt Vonnegut! (I certainly have, some many, many times, and I enjoyed every minute.) Neither is Bayard, though it may seem so sometimes.
In my entries inspired by the book, it seems as if I am talking about myself an awful lot. Or consider my latest article, on parsing in CS courses. I read an article by Martin Fowler and ended up writing about my course and my opinions of CS courses. My guess is that most folks out there are more interested in Fowler's ideas than mine, yet I write.
This is another source of occasional guilt... Shouldn't this blog be about great ideas? When I write about, say, Bayard's book, shouldn't the entry be about Bayard's book? Or at least about Bayard?
Bayard helps me to answer these questions. Let's switch from Montaigne, the focus of my last entry on this topic, to Wilde. The lead quote of Bayard's Chapter 12 was the first passage of the book to seize my attention as I thumbed through it:
My experience writing this blog biases me toward shouting out, "Amen, Brother Bayard!" But, if it is true that all of my writing is a pretext for writing my autobiography, then it is all the more remarkable that I have any readers at all. Certainly you all have figured this out by now.
Bayard claims -- and Wilde agrees -- that it cannot be any other way. You may find more interesting people writing about themselves and read what they write, but you'll still be reading about the writer. (This is cold consolation for someone like me, who knows myself to be not particularly interesting!)
Bayard explores Wilde's writing on this very subject, in particular his The Critic as Artist (HB++). Bayard begins his discussion with the surface connection of Wilde offering strident support for the idea of not reading. Wilde says that, in addition to making lists of books to read and lists of books worth re-reading, we should also make lists of books not to read. Indeed, a teacher or critic would do an essential service for the world by dissuading people from wasting their time reading the wrong books. Not reading of this sort is a "power acquired by specialists, a particular ability to grasp what is essential".
Bayard then moves on to a deeper connection. Wilde asserts in his typical fashion that the distinction between creating a work of art and critiquing a work of art is artificial. First, the artist, when creating, necessarily exercises her critical faculty in the "spirit of choice" and the "subtle tact of omission"; without this faculty no one can create art, at least not art worth considering. This is an idea that most people are willing to accept, especially those creative people who have some awareness of how they create.
But what of the critic? Many people consider critics to be parasites who at best report what we can experience ourselves and and at worst detract from our experience with their self-indulgent contributions.
Criticism is itself an art. And just as artistic creation implies the working of the critical faculty, and, indeed, without it cannot be said to exist at all, so Criticism is really creative in the highest sense of the word. Criticism is, in fact, both creative and independent.
This means that a blogger who primarily comments on the work of others can herself be making art, creating new value. By choosing carefully ideas to discuss, subtly omitting what does not matter, the critic creates a new work potentially worthy of consideration in its own right. (Suddenly, the idea of a mashup comes to mind.)
The idea of critic as an independent creator is key. Wilde says:
The critic occupies the same relation to the work of art he criticises as the artist does to the visible world of form and colour, or the unseen world of passion and thought. He does not even require for the perfection of his art the finest materials. Anything will serve his purpose.
To an artist so creative as the critic, what does subject-matter signify? No more and no less than it does to the novelist and the painter. Like them, he can find his motives everywhere. Treatment is the test. There is nothing that has not in it suggestion or challenge.
Bayard summarizes other comments from Wilde in this way:
The work being critiqued can be totally lacking in interest, then, without impairing the critical exercise, since the work is there only as a pretext.
But how can this be?? Because ultimately, the writer writes about himself. Freed from the idea that writing about something else is about that something, the writer is able to use the something as a trigger, a cue to write about the ideas that lie in his own mind. (Please read the first paragraph of the linked entry, if nothing else. Talk about not reading!)
As Wilde says,
That is what the highest criticism really is, the record of one's own soul.
Again, Bayard summarizes neatly:
Reflection on the self .. .is the primary justification for critical activity, and this alone can elevate criticism to the level of art.
As I read this chapter, I felt as if Bayard and Wilde were speaking directly to me and my own doubts as a blogger who likes to write about works I read, performances I see, and experiences as I have. It is a blogger's manifesto! Knowing and Doing feels personal to me because it is. Those works, performances, and experiences stimulate me to write, and that's okay. It is the nature of creativity to be sparked by something Other and to use that spark to express something that lies within the Self. Reading about Montaigne and his fear of forgetting what he had written was a trigger for me to write something I'd long been thinking. So I did.
I can take some consolation: This blog may not be worth reading, but not because I choose to connect what I read, see, hear, and feel to myself. It can be unworthy only to the extent that what is inside me is uninteresting.
By the way, I have just talked quite a bit about "The Critic as Artist", though I have never read it. I have only read the passages quoted by Bayard, and Bayard's commentary on it. I intend to read the original -- and begin forgetting it -- soon.
These three entries on Bayard's delightful little text cover a lot of ground in the neighborhood of guilt. We often feel shame at not having read something, or at not having grown from it. When we write for others, it is easy to become too concerned with getting things right, with being perfect, with putting on appearances. But consider this final quote from Bayard:
Truth destined for others is less important than truthfulness to ourselves, something attainable only by those who free themselves from the obligation to seem cultivated, which tyrannizes us from within and prevents us from being ourselves.
Long ago, near the beginning of this blog, I quoted Epictetus's The Enchiridion, via the movie Serendipity, of all places. That quote has a lot in common with what Bayard says here. Freeing ourselves from the obligation to seem cultivated -- being content to be thought foolish and stupid -- allows us to grow and to create. Epictetus evens refers to keeping our "faculty of choice in a state conformable to nature", just as Wilde stresses the role of critical faculty creating a work of art when we write.
Helping readers to see this truth and to release them from the obligation to appear knowing is the ultimate source of the value of How to Talk About Books You Haven't Read. Perhaps Bayard's will be proud that I mark it FB++.
I'm not yet thinking about my Programming Languages course this fall, but I wish I were. The first temptation came via my newsreader and Martin Fowler's recent piece ParserFear. Martin is writing a book on domain-specific languages and blogging occasionally on his ideas. This article is about just what the title says, programmers' often irrational fears of rolling a parser, which deter them from implementing their own DSLs. He speculates:
So why is there an unreasonable fear of writing parsers for DSLs? I think it boils down to two main reasons.
- You didn't do the compiler class at university and therefore think parsers are scary.
- You did do the compiler class at university and are therefore convinced that parsers are scary.
The first is easy to understand, people are naturally nervous of things they don't know about. The second reason is the one that's interesting. What this boils down to is how people come across parsing in universities.
CS students tend to learn about parsing for the first time in a compiler class, working on a large language with a full range of constructs. Parsing such languages is hard. In a few compiler courses, including my own, students still learn to build a parser by hand and so don't even have the chance to use parser generators as a labor- and pain-saving device. That's okay in a compiler course, which students take in large part to learn how their tools really work.
Martin doesn't suggest that we change the compiler course, and I don't either (though I'm open to possibilities). He does seem to think it's a shame that students are turned off to parsing and language design by first, and perhaps only, seeing them at their most complex. I agree and think that we should do more to introduce these ideas to students earlier.
I introduce students to the idea of parsing in my Programming Languages course, and ask students to write a few very small parsers to handle simple languages. I've been thinking for a while that I should do more in this area, and reading Martin's article has me itching to redesign the latter part of my course to allow more work with parsing and parsers. Another possibility is to use parsing as the content of some of our early programming exercises, when students are nominally learning to program in a functional style. Students can certainly apply the programming techniques they are learning to translate simple data formats into more abstract forms. This might help them to begin to see that parsing is an idea broader than just general-purpose programming languages. It might ease their transition a couple of weeks later to the idea of syntax-as-data structure and allow us to do some simple work with DSLs.
I have tried the idea of parsing at its simplest with relative novices as early as CS 1. When I taught a media computation CS1, one of the last programming assignments was to write a program to read a file of simple graphics commands and produce the desired graphical image. The idea was to bypass Java's verbose syntax for doing simple AWT/Swing graphics and allow non-programmers (artists) to make images. I asked students to implement a couple of simple commands, such as "draw line", and create at least one command of their own. I expected all of their graphics languages to be "straight-line", with no control or data structures, but that didn't mean that the resulting DSLs were not useful. They were just simple. A couple of students did really interesting work, creating very high-level commands for swirls and splashes. These students wrote methods to interpret those command using control and data structures that their "programmers" didn't have to know about.
Any change to my Programming Languages needs to be "footprint-neutral", to use Shriram Krishnamurthi's phrase. Anything I add has to fit in my fifteen-week course and either displace existing material or work in parallel. Shriram used this phrase in the broader context of rejiggering the teaching of teaching of programming languages within the core ACM curriculum, which a recent SIGPLAN-sponsored workshop tried to do. After having just read Martin's article on parsing, I was eager to refresh my memory on where parsing fits into the core curriculum proposal. Parsing falls under knowledge unit PL3, Language Translation, which has two hours allotted to it in the core. (An optional knowledge unit on Language Translation Systems includes more.) Interestingly, the working group Shriram reports on recommends cutting those two hours to zero, on the grounds that the current coverage is too superficial, and using those hours to build up a 10-hour unit on Functional Programming. That's a worthy goal, though I haven't hard a chance to think deeply about the proposal yet.
Working with constrained resources sometimes requires making tough choices. I know that Shriram and the people with whom he worked think that parsing is a worthwhile topic for CS students to know, so perhaps they have in mind something like what I suggested above: piggybacking some coverage of parsing on top of the coverage of functional programming. In any case, I think I'll work on finding more ways for my Programming Languages students to engage parsing and domain-specific languages.
I haven't written about running for a while now, in large part because I have not been running for a while now. On May 2, I ran a great fast workout, my fastest in many months. I was stoked and feeling ready to train for the Sturgis Falls half-marathon at our local summer festival.
Later that morning, I came down with the same symptoms that had ransacked me for six months last year: headache and a strange but deep fatigue. Exertion magnified both inordinately. So I rested.
After nine days, I felt a little better but not well. I tried 3.5 easy miles and was back at the beginning. So I rested.
I felt a little better at times but never well. I went to the doctor, who revisited our diagnostic efforts from last year. He drew an extra large dose of blood and ran tests for a wide array of possible causes: iron deficiency, B-complex vitamin deficiency; liver, kidney, and thyroid; myelomas, mononucleosis, and several others. The tests came back clean.
That is great news; I don't yet seem to be sick with anything major. But it is also bad news; we don't know what's up.
I have been feeling a bit better but, still, not well. Late last week, I finally began to feel as if I was losing fitness in my legs. Surely my legs were leaving me earlier, but now they felt like it.
This morning I decided to test the road again. I ran 3 easy miles. My hamstrings said, "Remember me?" The rest of my legs felt like they'd been off for five weeks. So far, I have not had the dull ache in my head, only the fuzziness that accompanies the unusual fatigue. I have managed to work all day. That feels like good news.
At this point, the June 29 half-marathon is out. If I can get back to regular runs in the next two weeks, I may try to run the accompanying 5K at a recreational pace. If things go ll right the rest of the month, I think I will try to run an October marathon -- relatively local, and relatively relaxed. But a small desire is still there.
I'll run again tomorrow.
In my last entry, I talked about Pierre Bayard's How to Talk About Books You Haven't Read, which I have, indeed, read. Bayard started with the notion that no one should feel shame about not having read a book, even when we are called upon to talk abut it. He eventually reached a much more important idea, that by freeing ourselves from this and other fears we have about books and learning we open ourselves to create art of our own. This entry looks at the bigger idea.
The issues that Bayard discusses throughout the book touch me in several personal and professional ways. I am a university professor, and as a teacher I am occasionally asked by students to talk about books and papers. I've read many of these, but not all; when I have read a work, though, I may well have forgotten a lot of it. In either case, I can find myself expected to talk intelligently about a work I don't know well. Not surprisingly, students show considerable deference to their teachers, in part because they expect a level of authority. That's pressure. Personally, I sometimes hang with an interesting, literate, well-read crowd. They've all read a lot of cool stuff; why haven't I? They don't ask me that, of course, but I ask myself.
Bayard assures us "don't worry!", explains why not, and tells us how to handle several common situations in which we will find ourselves. That's the idea -- partly humorous, partly serious -- behind the book.
But there is more to the book, both humor and truth, that connected with me. Consider:
Reading is not just acquainting ourselves with a text or acquiring knowledge; it is also, from its first moments, an inevitable process of forgetting.
Until I started writing this blog, I did not have a good sense of how bad my memory is for what I have read. I've never had a high level of reading comprehension. Those standardized tests we all took in grade school showed me to be a slow reader with only moderate comprehension, especially when compared to performance in school. One of the best outcomes for me of writing this blog has been to preserve some of what I read, especially the part that seems noteworthy at the time, before I start to forget it.
The chapter that contains the sentence quoted above begins with this subtitle:
Montaigne writes with fear about his forgetfulness, the loss any memory of having read a book. Does that still count? In one sense, yes. I've held Ringworld in my hands and taken in the words on each page. But in most ways I am today indistinguishable from a person who has never read the book, because I don't remember much more than the picture on the cover. Bayard explores this and other ways in which the idea of "to read" is ambiguous and bases his advice on the results.
How about any of the many, many technical computer science books I've read? The same fate. There is one solace to be had when we consider books that teach us how to do something. The knowledge we gain from reading technical material can become part of our active skill base, so that even after we have forgotten "knowledge that" the content of a compiler text is true, we can still have "knowledge how" to do something.
But reading is not the end of forgetting. Montaigne was an essayist. What about writing? Montaigne expects his loss to extend to his own work:
It is no great wonder if my book follows the fate of other books, and if my memory lets go of what I write as of what I read, and of what I give as of what I receive.
Forgetting what I have written is a sensation I share with Montaigne. Occasionally, I go back and re-read an old entry in this blog, or a month of entries, and am amazed. Some times, I am amazed that I wrote such drivel. Other times, I am amazed that I had such a good idea and managed to express it well. And, yes, I am often amazed to be reminded I have read something I've forgotten all about. In the best of these cases, the entry includes a quotation or, even better, a link to the work. This allows me to read it again, if I desire. I usually do.
That is good news. We can hold at bay the forgetting of what we read by re-reading. But there is another risk in forgetting: writing the same thing again. Bayard reports Montaigne's fear:
Incapable of remembering what he has written, Montaigne finds himself confronted with the fear of all those losing their memory: repeating yourself without realizing it....
Loss of memory creates an ambiguity in the writer's mind. It's common for me when writing a blog entry to have a sense of deja vu that I've written the same thing before. Sometimes my mind is playing tricks on me, due to the rich set of links in my brain, but sometimes I am and have forgotten. The fear in forgetting what we have written is heightened by the fear that what we write is unremarkable. We may remember the idea that stands out, but how are we to remember the nondescript? I often feel as Montaigne did:
Now I am bringing in here nothing newly learned. These are common ideas; having perhaps thought of them a hundred times, I am afraid I have already set them down.
I feel this almost no matter what I write. Surely my thoughts are common; what value is there in writing them down for others to read? That's why it was good for me to realize at the very beginning that I had to think that I was writing for myself. Only then would I find the courage to write at all and maybe benefit someone else. When confronted by a sense that I am writing the same ideas again, I just have to be careful. And when I do repeat myself, I must hope that I do it better the second time, or at least differently enough, to add something that makes the new piece worth a reader's time.
The danger in forgetting what I have written is not only in writing again. What about when a reader asks me about something I have written? Montaigne faced this fear, too, as Bayard writes:
But fear of repeating himself is not the only embarrassing consequence of forgetting his own books. Another is that Montaigne does not even recognize his own texts when they are quoted in his presence, leaving him to speak about texts he hasn't read even though he has written them.
That is at least two layers of not reading more than most of us expect to encounter in any situation! But the circumstance is quite real. When someone sends me e-mail asking about something I've forgotten I wrote, I have the luxury of time to re-read (there it is again!) before I respond. My correspondent is likely none the wiser. But what if they ask me in person? I am right where Bayard says I will be, left to respond in many of the ways he describes.
By writing about what I read and think about, there is a great risk that people will expect me to be changed by the experience! I did not do myself any favors when I chose a name for my blog, because I create an expectation about both knowing and doing. I certainly hope that I am changed by my experience reading and writing, but I know that often I have not changed, at least sufficiently. I still give lame assignments. I'm not that much better as a teacher at helping students learn more effectively. My shortcoming is all the more obvious when students and former students read my blog and are able to compare their experiences in my classes with my aspirations.
This is actually more a source of guilt for me than being thought not to have read a book. I know I am not as good as all the things I've read might lead one to believe, or even as good as what I've written (which sets a much lower bar!). If I am not growing, what is the point?
Of course, I probably am changing, in small increments beneath the scale of my perception. At least I hope so. Bayard doesn't say this in so many words, but I think it is implicit in how he approaches reading and not reading. For him, there is no distinction between the two:
We do not retain in memory complete books identical to the books rememeberd by everyone else, but rather fragments surviving from partial readings, frequently fused together and recast by our private fantasies.
This is a central theme for Bayard, and for me as well. He talks at length about the different ways our inner conception of books and libraries affects the act of reading any book. I often wonder how much of what I report about a book or paper I read is a product of me imposing my own view on what the writer has said -- not what is there, not what the author has intended, what distorts the writer's meaning? How much of what I am writing about Bayard's book reflects accurately the book he wrote?
Bayard would be unconcerned. On his view, I could no more not impose my inner book on the outer one than to be Bayard himself. No one can avoid distortion (in an objectivist sense) or imposition of self (in a subjectivist sense). What distinguishes the master is how forcefully and creatively one does so. Private fantasy, indeed!
To conceive of reading as loss ... rather than as gain is a psychological resource essential to anyone seeking effective strategies for surviving awkward literary confrontations.
Can I admit that I have forgotten something I've read or written? Certainly; I do it frequently. The key is to talk about the work as who I am in the present. I don't even need to explicitly acknowledge the loss, because the loss is a given. But I must talk without embarrassment and without any pretension that I remember exactly what I said or thought then. The human mind works in a certain way, and I must accept that state of affairs and get down to the business of learning -- and creating -- today.
I have another million to my credit, and it was a marvelous little surprise.
Popular culture is full of all sorts of literary references with which you and I are supposed to be familiar. Every year brings another one or two. The Paradox of Choice. The Tipping Point. The Wisdom of Crowds. Well-read people are expected, well, to have read the books, too. How else can we expect to keep up with our friends when they discuss these books, or to use the central wisdoms they contain in knowing ways?
I have a confession. I have read only two or three chapters of The Wisdom of Crowds. I have read only an excerpt from The Tipping Point that appeared in the New Yorker or some other literary magazine. And while I've seen a Google talk by Barry Schwartz on-line, I may not have read anything more than a short precis of the work. Of course, I have learned a lot about them from my friends, and by reading about them in various other contexts. But, strictly speaking, I have not read any of them.
To be honest, I feel no shame about this state of affairs. There are so, so many books to read, and these just have not seemed important enough to displace others from my list. And in the case of The Wisdom of Crowds, I found that one or two chapters told me pretty much all I needed to understand the Big Idea it contained. Much as Seth Godin has said about many popular business books, many books in the popular canon can be boiled down to much shorter works in their essence, with the rest being there for elaboration or academic gravitas.
For airplane reading on my trip to the workshop at Google, I took Pierre Bayard's How to Talk About Books You Haven't Read. Bayard's thesis is that neither I nor anyone else should feel shame about not having read any given book, even if we feel a strong compulsion to comment, speak, or write about it. In not reading and talking anyway, we are part of a grand intellectual tradition and are, in fact, acting out of necessity. There are simply too many books to read.
This problem arises even in the most narrow technical situation. When I wrote my doctoral dissertation, I surely cited works with which I was familiar but which I had not "read", or, having read them, had only skimmed them for specific details. I recall feeling a little bit uneasy; what if some party of the book or dissertation that I had not studied deeply said something surprising or wrong? But I knew a lot about these works in context: from other people's analyses, from other works by the same author, and even from having discussed the work with the author him- or herself. But in an important way, I was talking about a work I "had not read".
How I could cite the work anyway and still feel I was being intellectually honest gets to one of the central themes of Bayard's book: the relationships between ideas are often more important than the ideas themselves. To understand a work in the context of the universal library means more than just to know the details of the work, and the details themselves are often so affected by conditions outside of the text that they are less reliable than the bigger picture anyway.
First, let me assure you. Bayard wrote this book with a wink in his eye. At times, he speaks with a cavalier sarcasm. He also repeats himself in places; occasional paragraphs sound as if they have been lifted verbatim from previous chapters.
Second, this book fits Seth Godin's analysis of popular business books pretty well. Two or three chapters were sufficient to express the basic idea of this book. But such a slim product would have missed something important. How to Talk About Books You Haven't Read started as a joke, perhaps over small talk at a cocktail party, but as Bayard expanded on the idea he ended up with an irreverent take on reading, thinking, and understanding that carries a lot more truth than I might first have imagined. Readers of this blog who are software patterns aficionados might think of Big Ball of Mud in order to understand just what I mean: antipattern as pattern, when looked at from a different angle.
This book covers a variety of books that deal in some way with not reading books but talking about them. Along the way, Bayard explores an even wider variety of ideas. Many of these sound silly, even wrong, at first, and he uses this to weave a lit-crit tale that is perfect parody. But as I read, I kept saying, "Yeah, but..." in a way, this really is true.
For example, Bayard posits that reading too much can cause someone to lose perspective in the world of ideas and to lose one's originality. In a certain way, the reader subordinates himself to the writer, and so reading too much means always subordinating to another rather than creating ideas oneself. We could read this as encouragement not to read (much), which would miss his joke. But there is another level at which he is dead-on right. I knew quite a few graduate students who learned this firsthand when they got into a master's program and found that they preferred to immerse themselves in the research of others than to do creative research of their own. And there many blogs which do a fine job reporting on other people's work but which never seem to offer much new. (I struggle with that danger each time I write in this blog.)
Not reading does not mean that we cannot have an opinion. My friends and I are examples of this. Students are notorious for this, and Bayard, a lit professor, discusses the case of students in class at some length. But I was most taken by his discussion of Laura Bohannan's experience telling the story of Hamlet to the Tiv people of West Africa. As she told the story, the Tiv elders interpreted the story for her, correcting her -- and Western culture, and Shakespeare -- along the way. One of the interpretations was a heterodoxy that has a small but significant following among Shakespeare scholars. The chief even ventured to predict how the story ended, and did a pretty good job. Bayard used this as evidence that not reading a book may actually leave our eyes open to new possibilities. Bohannan's story is available on-line, and you really should read it -- it is delightful.
Bayard talks about so many different angles on our relationship with books and stories about them, including
One chapter focuses on our encounters with writers, and the ticklish situations they create for the non-reader and for the writer. In another, Bayard deals with the relationship among professors, students, and books. It made me think about how students interpret the things I say in class, whether about our readings or the technical material we are learning. Both of these chapters figure in a second entry I'm writing about this book, as well as chapters on the works of Montaigne and Wilde.
One chapter uses as his evidence the campus novels of David Lodge, of whom I am a big fan. I've never blogged about them, but I did use the cover of one of his books to illustrate a blog entry. Yet another draws on Bill Murray's classic Groundhog Day, an odd twist in which actually reading books enters into Bayard's story and supports his thesis. I have recommended this film before and gladly do so again.
As in so many situations, our fear of appearing weak or unknowledgable is what prevents us from talking freely about a book we haven't read, or even to admit that we have not read it. But this same fear is also responsible for discouraging us from talking about books we have read and about ideas we have considered. This is ultimately the culprit that Bayard hopes to undermine:
But our anxiety in the face of the Other's knowledge is an obstacle to all genuine creativity about books. The idea that the Other has read everything, and thus is better informed than us, reduces creativity to a mere stopgap that non-readers might resort to in a pinch. In truth, readers and non-readers alike are caught up in an endless process of inventing books, whether we like it or not, and the real question is not how to escape that process, but how to increase its dynamism and its range.
Bayard's book is worth reading just for his excerpts of other books and for his pointer to the story about the Tiv. I should probably feel guilt at not having read this book yet when so many others have, but I'm just happy to have read it now.
While reading on the plane coming home, I glanced across the aisle and noticed another passenger reading Larry Niven's Ringworld. I smiled and thought "FB++", in Bayard's rating system. I could talk about it nonetheless.