I first became acquainted with Pat Conroy's work when, as a freshman in college, I watched The Great Santini as a requirement for one of my honors courses. This film struck me as both sad and hopeful. Since then, I have seen a couple of other movies adapted from his novels.
A few years ago, I read his My Losing Season, a memoir of his final season as a basketball player at The Citadel, 1966-1967. Conroy's story is essentially that of a mediocre college-level athlete coming to grips with the fact that he cannot excel at the thing he loves the most. This is a feeling I can appreciate.
The previous paragraph comes from a short review of My Losing Season written only a few weeks before I began writing this blog. That page gives summaries of several books I had read and enjoyed in the preceding months. (It also serves as an indication of how eager I was to write for a wider audience.)
This break I am reading Conroy's latest book, My Reading Life. It is about his love affair with words and writing, and with the people who brought him into contact with either. I stand by something I wrote in that earlier review: "Conroy is prone to overwrought prose and to hyperbole, but he's a good story teller." And I do love his stories.
I also value many of the things he values in life. In a moving chapter on the high school English teacher who became his first positive male role model and a lifelong friend and confidant, Conroy writes:
If there is more important work than teaching, I hope to learn about it before I die.
Then, in a chapter on words, he says:
Writing is the only way I have to explain my own life to myself.
Even more than usual, teaching and writing, whether prose or program, are very much on my mind these days. Reading My Reading Life is a great way to end my year.
Last evening, my wife and I attended the wedding of one of my former graduate students. He is from India, and his new wife is from Russia. This was a small ceremony and party, with only a few of their closest friends. They will have big celebrations in their homelands next year to commemorate the marriage with extended family. This celebration consisted of a simple civil ceremony, beautiful wedding vows, and lots of fun courtesy of their multicultural friends.
I was honored that he asked me to attend, and more honored that he considers me a close enough friend to invite to such a small and intimate affair. He arrived at my university as a student in one of my classes. Soon, he chose to work with me as his thesis advisor. In the years since he graduated, we have become colleagues and friends, talking first about our careers then about our lives. I consider him to be a friend of the highest order.
The academic world sometimes delivers great gifts to us. There was no particular reason for this talented, hard-working, generous, and loyal young man to arrive on our doorstep, among all the many schools he could have chosen. When he did, I received the good fortune of working with him academically for two years and then the good fortune of a great friend thereafter.
One of the traditions the groom and bride celebrated at their wedding was that anyone who wanted to give a toast could do so. Nearly everyone in attendance who knew either of them did so, and the groom himself spoke several times. About half way through the dinner and social time, my friend addressed the group, answering the often-asked question, how does a young man from Hyderabad end up at regional university in the middle of America's cornfields? He told a story about the e-mail he and I exchanged as he looked for an American grad school. Though we did not know it at the time, that was the beginning of our friendship.
This story honored me, far beyond the wedding invitation, and humbled me. It was an unexpected gift as the snow began to fall at the outset of the holiday weekend.
I wish Shri and Katya a lifetime of love and their own deep friendship. A friend is an eternal gift.
This is my last day at the office before Christmas, and my mind has turned to 2011 already. I'll do some work next week but hope to spend most of my week celebrating the holiday with my families. Besides, this is the time when a professor mind naturally turns to spring semester courses.
I have another reason to think about the future. This is the last year of my second three-year term as department head, so the dean is conducting a review of my performance. Implicit in these reviews is that it's a natural time for the dean to decide whether to continue with the current head or go in a different direction.
The head also makes the decision. There is a lot I like about being a department head, and a lot that I can do to help the faculty and students that I could not do otherwise. But it changes the shape and tenor of every day. At research schools, chairs often count the days of their terms from Day One. For a guy who is a researcher, programmer, or teacher at heart, there is precious little time to think about and do those things.
I head into to breaking thinking about the future. I have a lot of people's words rolling around in my head. Last week, Seth Godin said
If someone asks you ["What are you working on?"], are you excited to tell them the answer?
I hope so. If not, you're wasting away.
Last year, Chad Fowler asked:
But I think a good first step is to ask yourself the question: "What would I rather be doing right now?" And then, "Why is that not what I'm doing?"
... and Derek Sivers exclaimed:
No more yes. It's either HELL YEAH! or no.
... and Hugh MacLeod doodled: Life is too short not to do something that matters.
The recurring theme is: Take control of life. Don't drift. Don't let others determine your life. Godin goes an extra step and reminds us that we can apply this advice without changing our careers or job titles:
No matter what your job is, no matter where you work, there's a way to create a project ... where the excitement is palpable.... Hurry, go do that.
Plenty for my mind, conscious and subconscious, to mull over.
Steve Martin's memoir, "Born Standing Up", tells the story of how Martin's career as a stand-up comedian, from working shops at Disneyland to being the biggest-selling concert comic ever at his peak. I like hearing people who have achieved some level of success talk about the process.
This was my favorite passage in the book:
The consistent work enhanced my act. I Learned a lesson: It was easy to be great. Every entertainer has a night when everything is clicking. These nights are accidental and statistical: Like the lucky cards in poker, you can count on them occurring over time. What was hard was to be good, consistently good, night after night, no matter what the abominable circumstances.
"Accidental greatness" -- I love that phrase. We all like to talk about excellence and greatness, but Martin found that occasional greatness was inevitable -- a statistical certainty, even. If you play long enough, you are bound to win every now and then. Those wines are not achievement of performance so much as achievements of being there. It's like players and coaches in athletics who break records for the most X in their sport. "That just means I've been around a long time," they say.
The way to stick around a long time, as Martin was able to do, is to be consistently good. That's how Martin was able to be present when lightning struck and he became the hottest comic in the world for a few years. It's how guys like Don Sutton won 300+ games in the major leagues: by being good enough for a long time.
Notice the key ingredients that Martin discovered to becoming consistently good: consistent work; practice, practice, practice, and more practice; continuous feedback from audiences into his material and his act.
We can't control the lightning strikes of unexpected, extended celebrity or even those nights when everything clicks and we achieve a fleeting moment of greatness. As good as those feel, they won't sustain us. Consistent work, reflective practice, and small, continuous improvements are things we can control. They are all things that any of us can do, whether we are comics, programmers, runners, or teachers.
On Thursday, my students presented their Klein compilers. Several of the groups struggled with code generation, which is a common experience in a compiler course. There are a lot of reasons, most prominently that it's a difficult task. (Some students' problems were exacerbated by not reading the textbook...)
Still, all four groups managed to get something working for a subset of the language. They worked really hard, sometimes trying crazy ideas, all in an effort to make it work.
Over the years, I have noticed that some students have this attribute: they find a way to get things done. Whatever constraints they face, even under sub-optimal conditions they create for themselves, they find a way to solve the problem or make the program meet the spec. I'm surprised how often some students get things done despite not really understanding what they are doing! (Of course, sometimes, you just gotta know stuff.)
This reminds me of a conversation I had at Clemson University back in 1994 or 1995. I was attending and NSF workshop on closed labs. We were attending the midweek social event that seems de rigeur at weeklong workshops, chatting with some Clemson CS profs who had joined us for the evening and some AP CS graders who were also stationed at Clemson for the week. The AP folks talking about grading programs, the sort our students write in AP CS, CS1 and CS2.
One Clemson prof was surprised by how much weight the CS1 profs give to style, documentation, and presentation, relative to correctness. He said that he taught CS1 differently. Programming is hard enough, he said, that if you can find students who can wrote code, you should do whatever you can to encourage and develop them. We can teach style, presentation, and documentation standards to those students. Trying to teach more advanced programming skills to people who produce nice-looking programs but don't seem to "get it" is much, much harder.
He was expressing a preference for students who get stuff done.
In practice, students who major in CS from all across the spectrum. As a professor, I would like for my courses and our academic programs to help develop the "gets things done" attribute in our students, wherever they start along the spectrum. This requires that we help them grow not only in knowledge but also work habits. Perhaps most important is to help students develop a certain attitude toward problems, a default way of confronting the challenges they invariably encounter. Attitudes do not change easily, but they can evolve slowly over time. We profs can set a good example in how we confront challenges in class. We can also create conditions that favor a resilient approach to tough problems.
It was good for me to end the semester -- and the 2010 calendar year -- seeing that, whether by nature or nurture, some of our CS majors manage to get stuff done. That bodes well for success when they leave here.
... you get to the code generation part of the compiler course you are teaching. You realize that you have forgotten the toy assembly language from the textbook for its toy virtual machine, so you have to relearn it. You think, "It's gonna be fun to write programs in this language again."
Assembly language? A toy assembly language? Really?
I just like to program. Besides, after programming in Klein this semester, a language I termed as an integer assembly language, moving to a very RISC assembly doesn't seem like that big a step down. Assembly language can be fun, though I don't think I'd want to program in it for a living!
Last week, I followed a links from John Cook to the essay In Praise of the Lecture. This is countercultural among academics these days. As you probably know, lecture is out of fashion. My colleagues in the sciences still rely on them pretty heavily, some proudly and defiantly, but even many scientists speak as lectures are a bad thing. They are dead, boring. Because they don't involve the student, they don't engage the student's mind. As a result, learning doesn't happen.
I have some courses in which I lecture almost not at all. In most others, I mix lecture and exercises to create a semi-active classroom. Right now,, though, I am coming out of my compilers course, in which I lecture a lot. Looking back, I know that on many days I need to generate more excitement for my students. Yet the simple fact is that this course material seems to require more lecture than exercise on most days. Whatever compilers textbook I use, I feel as if I need to explain ideas and techniques for a second time in hopes of making them clear.
The thing is, lecture doesn't have to be boring. The class periods I recall from my undergrad days were all lectures, and I recall them fondly, with admiration for the speaker and deep appreciation for the subject. The best lecturers roused emotion in their audience and exhorted us to action. A great lecture has a different rhythm from other class sessions. "In Praise of the Lecture" reminds me that this is true.
I especially enjoyed Carter's section titled "The Lecture as a Personal Act". Here is a snippet:
Closely related to the idea of the lecture as a moral act is the idea of the lecture as a personal act. True education is always about personal growth toward the Truth. Some would charge the lecture with being the paradigmatic act of arrogance: one person stands there with all the truth while the rest sit quietly as supplicants. But this is to distill the university experience into only one of its moments, as if the slow movement of the pendulum to the right were never balanced by its eventual arc back to the left. To read in preparation and to argue in response are the parts of the educational experience set in motion by the lecture, which acts a fulcrum.
In order for a lecture to work, students must be engaged: not in some active exercise within the class period, but across a broader swath of time. First, they must read in order to ready their minds. Then comes the lecture, which tells a second story. It is a living incarnation of what the author describes. Students see what the professor focuses on, what the professor chooses to leave in, what the professor omits, and what excites the professor. They are introduced to questions that lie at the edges of the ideas and techniques and lines of code. The best lecturers do this in context, so that students hear a story personalized to that time, place, and audience.
Finally, students must engage the ideas afterwards. In the humanities, this might take the form of discussion in which everyone in the room, lecturer included, argue their cases -- and maybe even someone else's case -- in order to really understand. That can happen in the sciences, too, but just as important for the science student is application: taking ideas into the lab to try them out, see when they work and when they don't, bend them to fit the peculiarities of a real problem. Only then are they and the professor ready to have a truly enlightening discussion.
The biggest problem with lecture may be that it expects so much of the students who hear it. They must read and think before class. They must apply ideas and think after. Building courses around in-class exercises may well lead students to think that all the learning will happen in class and discourage the kinds of learning that happen outside of class. I realize that this likely overstates the case, and romanticizes the lecture, but I still think there is some truth in it.
Lecture also expects more of the teacher. It's easy to give boring lectures by reading old notes or cribbing from the mind-numbing slide deck that seems to come as a matter of course with every textbook these days. To lecture well, the teacher must engage the material, too, and personalize it, both to herself and to her students. That's what Carter means when he says that a lecture occurs in a specific place and time. Whether we admit it or not, a lecture is a personal act, whether done well or not. It is and should be unique. Perhaps this is why I feel I have to rework every lecture every time I deliver it.
Actually, I want to. That's how I engage the material and make it say what Eugene Today feels and thinks. Even with a course on compiler construction, I change from offering to offering, and how I present the material must change. Besides, every lecture I give can be better. I need to work toward that goal a little every time I give them.
I'm not suggesting that every course be taught in a lecture format, or even every session of any course. I will continue to use in-class exercises, discussion, and any other technique I can to make my courses as effective as I can. I'm just saying that lecture has a place, and just maybe it can help us to create the right expectations for our learning environments.
In the end, whether we lecture or discuss, whether we use group exercises or clicker systems and multiple choice questions, it all probably comes down to this:
"My students do not learn what I teach them. They learn what I am excited about."
Please forgive me if this comes off sounding a bit too romantic for a computer science professor. The semester is coming to a close, and we are in the Christmas season.
The Toyota Production System encourages workers to solve every problem two ways. First, you fix the issue at hand. Second, you work back through the system to determine the systemic reason that the issue arose. In this way, you eliminate this as a problem in the future, or at least make it less likely.
As I wrote recently, I don't think of writing software as a production process. But I do think that software developers can benefit from the "solve it twice" mentality. When we encounter a bug in our program or a design problem in our system or a delivery problem on a project, we should address the specific issue at hand. Then we should consider how we might prevent this sort of problem from recurring. There are several ways that we might improve:
This approach would benefit us as university students and university professors, too. If students and professors thought more often in terms of continuous improvement and committed to fixing problems the second time, too, we might all have lower mean times to competence.
I'm on a mailing list with a bunch of sports fans, many of whom are also CS academics and techies. Yesterday, one of the sysadmins posted a detailed question about a problem he was having migrating a Sun Solaris server to Ubuntu, due to a conflict between default /etc/group values on the two operating systems. For example, the staff group has a value of 50 on Ubuntu and a value of 10 on Solaris. On Ubuntu, the value 10 identifies the uucp group.
Another of the sysadmins on the list wrote an even more detailed answer, explaining how group numbers are supposed to work in Unix, describing an ideal solution, and outlining a couple of practical approaches involving files such as /etc/nsswitch.conf.
After I read the question and the answer, I sent my response to the group:
Thank goodness I'm a CS professor and don't have to know how all this works.
I was joking, of course. Some people love to talk about how CS profs are disconnected from computing in the real world, and this is the sort of real-world minutia that CS profs might not know, or even have to know if they teach courses on algorithms, intro programming, or software engineering. After seeing my friends' exchange and seeing all that Unix guru-speak, I was happy to play to the stereotype.
Of course, the numbers used to implement Unix group numbers really are minutia and something only practicing sysadmins would need to know. The professor who teaches our systems courses is deeply versed in these details, as are the prof or two who manage servers for their courses and research. There certainly are CS academics divorced from reality, but you can say that of any group of people. Most know what they need to know, and a bit more.
Later in the day, I became curious about the problem my friends had discussed, so I dug in, studied a bit, and came to understand the problem and candidate solutions. Fun stuff.
Our department has recently been discussing our curriculum and in particular the goals of our B.A. and B.S. programs: What are the desired outcomes of each program? That is jargon for the simpler, "When students graduate, what would we like for them to be able to do?" For departments like ours, that means skills such as being able to write programs of a certain size, design a database, and choose appropriate data structures for solving a specific problem.
I was thinking about the Unix exchange on my mailing list in this context. Let's be honest... There is a lot of computer science, especially CS as it is applied in specific technology, that I don't know. Should I have known to fix my friend's problem? Should our students? What can we reasonably expect of our students or of ourselves as faculty?
Obviously, we professors can't know everything, and neither can our students. That is true in any discipline and especially in one like CS, which changes and grows so fast. This is one of the reasons it is so important for us to define clearly what we expect our programs to achieve. The space of computing knowledge and skills is large and growing. Without a pretty good idea of what we are hoping to achieve with our courses and curricula, our students could wander around in the space aimlessly and not having anything coherent to show for the time or effort. Or the money they spent paying tuition.
So, when I first read my friends' messages about Unix groups, I didn't know how to solve the problem. And that's okay, because I can't know everything about CS, let alone every arcane detail of every Unix distro out in the world. But I do have a CS degree and lots of experience. What difference should that make when I approach problems like this? If one of our graduates confronts this situation or one like it, how will they be difference from the average person on the street, or even the average college graduate?
Whatever specific skills our graduates have, I think that they should be able to come up to speed on computing problems relatively quickly. They should have enough experience with a broad set of CS domains and enough theoretical background to be able to make sense of unfamiliar problems and understand candidate solutions. They should be able to propose solutions that make sense to a computer scientist, even if the solutions lack a detailed knowledge of the domain.
That is, CS graduates should have a relatively low mean time to competence in most sub-areas of computing, even the ones they have not studied in detail yet.
For a smaller set of sub-areas, our students should also have a relatively low mean time to mastery. These are the areas they have studied in some detail, either in class or through project work, but which they have not yet mastered. A CS degree should put them in a position to master them more quickly than most educated non-computer scientists.
Mean time to competence (MTTC) and mean time to mastery (MTTM) are actually a big part of how I distinguish a university education from a community college education when I speak to prospective students and their parents, though I have never used those terms before. They always wonder about the value of technical certifications, which community college programs often stress, and why my department does not make study for certification exams an explicit goal for students.
We hope, I tell them, to put the student in a position of being ready to prepare for any certification exam in relatively short order, rather than spending a couple of years preparing them to take a specific exam. We also hope that the knowledge and experience they gain will prepare them for the inevitable developments in our discipline that will eventually make any particular certification obsolete.
I am not certain if mean time to competence and mastery are student learning outcomes in the traditional educational jargon sense of the word, or whether they are abstractions of several more concrete outcomes. In any case, I am left thinking about how we can help to create these outcomes in students and how we can know whether we are successful or not. (The agile developer in me says, if we can't figure out how to test our program, we need to break the feature down into smaller, more concrete steps.)
Whatever the practical challenges of curriculum design and outcomes, I think MTTC and MTTM are essential results for a CS program to generate. Indeed, they are the hallmark of a university education in any discipline and of education in general.
Now, to figure out how to do that.
We are in the last week of classes for the semester. I have not blogged much on my compilers course this time around, in fact not since the first week of classes. Part of that is being busy in other parts of my job, and part is that the course has gone relatively smoothly. I have a good set of students who have made steady progress writing their compilers. Our source language is a simple functional language, which gives us a good chance of having all four teams produce complete or nearly-complete systems. So I've not faced many problems teaching the course, and problems are the most salient triggers for me writing blog entries!
One thing I have noticed going well this semester is that several of the teams have been consciously taking small steps in the development process. That has helped those teams collaborate well internally and to learn together as they write parts of their program.
One thing I know that I can improve next time around is how I introduce and illustrate code generation. This is always one of the toughest phases of the compiler for most students, because they have so little experience with machine organization and assembly language programming, and what little they have came two or even three years ago. This term, I reorganized some of the earlier material and had an extra day or so in which to discuss code generation, but I did not put the time to good use.
Students need to see more concrete examples of code generation sooner to help them bridge the gap between AST and what their compiler must do. I fell into a common trap for professors: talking about things a bit too much and not showing and doing things often enough. I already have some ideas for how to fix this in the next iteration of the course. Prominent among them is working in class with the students to write small assembly language snippets and to produce a small code generator that illustrates some of the important ideas we discuss.
Fortunately, my students this time around seem to be on the road to success, whatever the shortcomings in how I've taught the course. This comes through their own efforts and through asking lots of questions outside of class. Good students usually make something good happen regardless of the conditions they face. We professors need to be thankful for this more often!
As Mike Feathers points out in his recent RailsConf 2010 address, we are all novices some of the time, whether it is in our problem domain or or solution domain. The real key is, do we learn something and get better? My students this semester seem to be doing that. I hope I am, too.
To be a moral human being is to pay, be obliged to pay, certain kinds of attention.
-- Susan Sontag, "The Novelist and Moral Reasoning"
For some reason, this struck me yesterday as important, not just as a human being, but also as a programmer. I am reminded that many of my friends and colleagues in the software world speak passionately of our moral obligations when writing code. The software patterns community, especially, harkens to Christopher Alexander's call regarding the moral responsibility of creators.
(If you want to read more from Sontag without tracking down her essay, check out this transcript excerpted from a speech she gave in 2004.)
As head of the Department of Computer Science at my university, I often receive e-mail and phone calls from people with The Next Great Idea. The phone calls can be quite entertaining! The caller is an eager entrepreneur, drunk on their idea to revolutionize the web, to replace Google, to top Facebook, or to change the face of business as we know it. Sometimes the caller is a person out in the community; other times the caller is a university student in our entrepreneurship program, often a business major. The young callers project an enthusiasm that is almost infectious. They want to change the world, and they want me to help them!
They just need a programmer.
Most of these projects never find CS students to work on them. There are lots of reasons. Students are busy with classes and life. Most CS students have jobs they like. Those jobs pay hard cash, if not a lot of it, which is more attractive to most students than the promise of uncertain wealth in the future. The idea does not excite other people as much as the entrepreneur, who created the idea and is on fire with its possibilities.
A few of the idea people who don't make connections with a CS student or other programmer contact me a second and third time, hoping to hear good news. The younger entrepreneurs can become disheartened. They seem to expect everyone to be as excited by their ideas as they are. (The optimism of youth!) I always hope they find someone to help them turn their ideas into reality. Doing that is exciting. It also can teach them a lot.
Of course, it never occurs to them that they themselves could learn how to program.
A while back, I tweeted something about receiving these calls. Andrei Savu responded with a pithy summary of the phenomenon I was seeing:
@wallingf it's sad that they see software developers as commodities. product = execution != original idea
As I wrote about at greater length in a recent entry, the value of a product comes from the combination of having an idea and executing the idea. Doing the former or having the ability to do the latter aren't worth much by themselves. You have to put the two together.
Many "idea people" tend to think most or all of the value inheres to having the idea. Programmers are a commodity, pulled off the shelf to clean up the details. It's just a small matter of programming, right?
On the other side, some programmers tend to think that most or all of the value inheres to executing the idea. But you can't execute what you don't have. That's what makes it possible for me and my buddy to sit around over General Tsao's chicken and commiserate about lost wealth. It's not really lost; we were never in its neighborhood. We were missing a vital ingredient. And there is no time machine or other mechanism for turning back the clock.
I still wish that some of the idea people had learned how to program, or were willing to learn, so that they could implement their ideas. Then they, too, could know the superhuman strength of watching ideas become tangible. Learning to program used to be an inevitable consequence of using computers. Sadly, that's no longer true. The inevitable consequence of using computers these days seems to be interacting with people we may or may not know well and watching videos.
Oh, and imagining that you have discovered The Next Great Thing, which will topple Google or Facebook. Occasionally, I have an urge to tell the entrepreneurs who call me that their ideas almost certainly won't change the world. But I don't, for at least two reasons. First, they didn't call to ask my opinion. Second, every once in a while a Microsoft or Google or Facebook comes along and does change the world. How am I to know which idea is that one in a gazillion that will? If my buddy and I could go back to 2000 and tell our younger and better-looking selves about Facebook, would those guys be foresightful enough to sit down and write it? I suspect not.
How can we know which idea is that one that will change the world? Write the program, work hard to turn it into what people need and want, and cross our fingers. Writing the program is the ingredient the idea people are missing. They are doing the right thing to seek it out. I wonder what it would be like if more people could implement their own ideas.