We offer a lot of our upper-division courses on a three-semester rotation. For the last few years, I have been teaching Programming Languages and our compilers course as a part of our rotation. Before I became department head, I taught Algorithms -- a course I love -- in the third slot. I passed the course on to someone else my first semester as head, and I've never gotten it back. The person who teaches it now is really good, and this leaves me to be a utility infielder, covering whatever most needs to be covered that semester. I've taught our intro course in this slot, as well as a set of 1-credit courses on individual programming languages.
This fall, I will teach a course I have never taught before: software engineering. This is a traditional introduction to the discipline for juniors and seniors:
Study of software life cycle models and their phases -- planning, requirements, specifications, design, implementation, testing, and maintenance. Emphasis on tools, documentation, and applications.
I have taught non- traditional software engineering before, in the form of two offerings of a course on agile software development. In fact, I taught that course during my first full semester after starting this blog, and it -- along with and sometimes in tandem with training for my second marathon -- provided a wealth of inspiration for my writing.
Long-term readers of this blog know that I have expressed skepticism about the software engineering metaphor, both in general and in some of the specifics, such as gathering requirements. Still, I respect the goals of the discipline and the effort and earnestness of its proponents. I also am able to put aside philosophical concerns in the interest of department concerns. We all agree that developing software, especially in the large, is a challenging endeavor that requires knowledge and skill. That is the goal of our course, and it will be the goal of my offering this fall.
The course I teach needs to stay pretty close to the traditional notion of software engineering, because that's what our curriculum calls for. By most accounts, employers who hire our students are pretty happy with what we teach in the course, in particular the breadth of exposure we give them. This is one of the constraints I face as I plan.
That said, I will certainly teach my own course. I will make sure that students are exposed to the agile approaches. Many of our alumni have told me that their employers are introducing elements of XP or Scrum into their software development processes, and that they wish they had learned a bit about them during their undergraduate studies. This is the right place for them to encounter agile principles and practices, as a different perspective on the phases of the software lifecycle.
I also tend more toward the working-code end of the spectrum, whereas this course has historically tended toward the modeling-and-abstraction end. I'd like to find a way to ensure that students see and experience both. Models are nothing more than pictures on a whiteboard or in a CASE tool until we can implement them in code. Besides, our students seem to graduate with an alarming lack of exposure to modern tools for version control, build management, and testing. I'd like to find a way for them to learn not only what the stages of software development are but also tools and practices for effectively evolving programs through those stages.
I'm looking for papers and ideas that can help me design a good course that balances several of these forces. Karen Reid's and Greg Wilson's Learning by doing is a great exemplar; it talks about how to introduce version control by using a tool like CVS or SVN to deliver, manage, and collect student assignments.
In the end, I want this course to serve well students wherever they end up after graduation, whether at a big-process company such as Rockwell Collins or a mostly-agile shop consisting of a few developers. Most of our graduates will end up working in several different development environments within a few years, regardless of where they land, so broad principles and understanding trump mastery of any particular skill set. But I also know that mastery plays a big role in how they will come to understand the principles.
Whatever I do, I want the course to be real, not merely an academic exercise.
My daily bleg: please send me any thoughts you have on this course, ways to organize it, or tools to use. As always, I value your suggestions and will gladly share the credit!
In real life there is no such thing as algebra.
-- Fran Lebowitz
At this time next week, I will be on my way to ChiliPLoP for a working session. Readers here know how much I enjoy my annual sojourn to this working conference, but this year I look forward to it with special fervor.
First, my day job the last few months -- the last year, really -- has been heavier than usual with administrative activities: IT task force, program review, budget concerns. These are all important tasks, with large potential effects on my university, my department, and our curriculum and faculty. But they are not computer science, and I need to do some computer science.
Second, I am still in a state of hopeful optimism that my year-long Running Winter is coming to an end. I put in five runs this week and reached 20 miles for the first time since October. The week culminated this morning in a chilly, hilly 8 miles on a fresh dusting of snow and under a crystal clear blue sky. ChiliPLoP is my favorite place to run away from home. I never leave Carefree without being inspired, unless I am sick and unable to run. Even if I manage only two short runs around town, which is what I figure is in store, I think that the location will do a little more magic for me.
Our hot topic group will be working at the intersection of computer science and other disciplines, stepping a bit farther from mainstream CS than it has in recent years. We all see the need to seek something more transformative than incremental, and I'd like to put into practice some of the mindset I've been exploring in my blog the last year or so.
The other group will again be led by Dave West and Dick Gabriel, and they, too, are thinking about how we might re-imagine computer science and software development around Peter Naur's notion of programming as theory building. Ironically, I mentioned that work recently in a context that crosses into my hot topic's focus. This could lead to some interesting dinner conversation.
Both hot topics' work will have implications for how we present programming, software development, and computer science to others, whether CS students are professionals in other disciplines. Michael Berman (who recently launched his new blog) sent a comment on my Sweating the Small Stuff that we need to keep in mind whenever we want people to learn how to do something:
I think that's an essential observation, and one that needs to be designed into the curriculum. Most people don't learn something until they need it. So trying to get students to learn syntax by teaching them syntax and having them solve toy problems doesn't teach them syntax. It's a mistake to think that there's something wrong with the students or the intro class -- the problem is in the curriculum design.
I learned algebra when I took trig, and trig when I took calculus, and I learned calculus in my physics class and later in queueing theory and probability. (I never really learned queueing theory.)
One of the great hopes of teaching computation to physicists, economists, sociologists, and anyone else is that they have real problems to solve and so might learn the tool they need to solve them. Might -- because we need to tell them a story that compels them to want to solve them with computation. Putting programming into the context of building theories in an applied discipline is a first step.
(Then we need to figure out the context and curriculum that helps CS students learn to program without getting angry...)
While running yesterday, I was thinking back to my entry on starting again. I say in that entry that having reach a certain level of accomplishment, however meager, makes starting over tough. It's not the same as a newcomer starting from scratch; in some objective sense the newcomer faces a bigger challenge. But starting over creates a new sort of psychological hurdle that adds to the physical challenge. When you've run 60-mile weeks and 10x800m speed workouts, trying to string together 3-mile runs on consecutive days can be, well, demoralizing.
My mind then wandered of to a message from a reader who is former student. He sent me a note in response to Small Surprises While Grading that went far beyond the specific surprises I mentioned -- great stuff on what had been in his mind while taking the course. I thought of this specific comment:
I'm not sure why [there were so many 0s in the course gradebook], but every assignment left me in a bad mood. My mood after each assignment was worse than the previous one. The second to last assignment I did well on, but left me angrier than I have been in a long time.
I wonder if part of this student's bad mood and anger comes from the same thing I'm feeling while running? He is a successful programmer, nearing the end of his undergraduate work. Then this course comes along and changes the rules: functional programming, Scheme, recursion, language grammars. Maybe he felt like he was starting over. Knowing what it felt like to master a programming language, to whip out programs, and to feel good after an assignment, perhaps this experience felt all the more painful, all the more insurmountable.
Though I have thought back to his message several times in the last couple of months, I didn't know to ask him this question until now. I'll ask. But regardless of his answer, I think the feeling I have occasionally while running these days gives me insight to what some students might be feeling.
I also now realize consciously one advantage that I have as a runner who "has reached the mountaintop" over a brand new runner: I know what it feels like to break through the barrier.
One of the more remarkable experiences on a race course is the dramatic deliverance from the depths of discomfort to the rebirth of spirit, endurance, and performance. There's nothing like breaking through the pain barrier, and finding a better and stronger runner on the other side.
-- from a Running Times article on endurance runner Lisa Smith-Batchen
Knowing that feeling is how I put the feeling of re-climbing the mountain in perspective, why any sense of despair seems to evaporate as quickly as it condenses in my mind. I will get back to long runs and faster times. The newbie may not be so confident.
Oh, and as for learning CS: If many students feel what my correspondent says he felt, or if a few students feel that way often, then that is probably sign of a failure in the design of our curriculum, or of my course. I don't mind that students feel uncomfortable for a while as they learn; that is both natural and necessary. Anger and despair are another matter.
When I was first asked to consider writing a blog piece for the Ada Lovelace Day challenge, I wasn't sure I wanted to. I don't usually blog with any particular agenda; I just write whatever is in my mind at the time, itching to get out. This was surely a topic I have thought and written about before, and it's one that I have worked on with people at my university and across the state. I think it is in the best interest of computer science to be sure that we are not missing out on great minds who might be self-selecting away from the discipline for the wrong reasons. So I said yes.
Soon afterwards, ACM announced Barbara Liskov as the winner of the Turing Award. I had written about Fran Allen when she won the Turing Award, and here was another female researcher in programming languages whose work I have long admired. I think the Liskov Substitution Principle is one of the great ideas in software development, a crucial feature of object-oriented programming, of any kind of programming, really. I make a variant of the LSP the centerpiece of my undergraduate courses on OOP. But Liskov has done more -- CLU and encapsulation, Thor and object-oriented databases, the idea of Byzantine fault tolerance in distributed computing, ... It was a perfect fit for the challenge.
But my first thought, Adele Goldberg, would not leave me. That thought grew out of my long love affair with Smalltalk, to which she contributed, and out of a memory I have from my second OOPSLA Educators' Symposium, where she gave a talk on learning environments, programming, and language. Goldberg isn't a typical academic Ph.D.; she is versatile, having worked in technical research, applications, and business. She has made technical contributions and contributions to teaching and learning. She helped found companies. In the end, that's the piece I wanted to write.
So, if my entry on Goldberg sounds stilted or awkward, please cut me a little slack. I don't write on assigned topics much any more, at least not in my blog. I should probably have set aside more time to write that entry, but I wrote it much as I might write any other entry. If nothing else, I hope you can find value in the link to her Personal Dynamic Media article, which I was so happy to find on-line.
At this point, one other person has written about Goldberg for the Lovelace Day challenge. That entry has links to a couple of videos, including one of Adele demonstrating a WIMP interface using an early implementation of Smalltalk. A nice piece of history. Mark Guzial mentions Adele in his Lovelace Day essay, but he wrote about three women closer to home. One of his subjects is Janet Kolodner, who did groundbreaking research on case-based reasoning that was essential to my own graduate work. I'm a fan!
My slogan is:
computing is too important to be left to men.
-- Karen Sparck-Jones, 1935-2007
We talk a lot about the state of women in computing. Girls have deserted computer science as an academic major in recent years, and female undergrad enrollment is at a historic low relative to boys. Some people say, "Girls don't like to program," but I don't think that explains all of the problem. At least a few women agree with me... During a session of the Rebooting Computing Summit in January, one of the men asserted that girls don't like to program, and one of the women -- Fran Allen, I think -- asked, "Says who?" From the back of the room, a woman's voice called out, "Men!"
A lot of people outside of computer science do not know how much pioneering work in our discipline was done by women. Allen won a Turing Award for her work on languages and compilers, and the most recent Turing Award was given to Barbara Liskov, also for work in programming languages. Karen Sparck-Jones, quoted above, discovered the idea of inverse document frequency, laying the foundation for a generation of advances in information retrieval. And these are just the ones ready at hand; there many more.
When people assert that women don't like (just) to program, they usually mean that women prefer to do computer science in context, where they can see and influence more directly the effects that their creations will have in the world. One of my heroes in computing, Adele Goldberg, has demonstrated that women can like -- and excel -- on both sides of the great divide.
(Note: I am not speaking of this Adele Goldberg, who is, I'm sure, a fine computer scientist in her own right!)
Goldberg is perhaps best known as co-author of several books on Smalltalk. Many of us fortunate enough to come into contact with Smalltalk back in the 1980s cut our teeth on the fabulous "blue book", Smalltalk-80: The Language and Its Implementation. You can check out a portion of the blue book on-line. This book taught many a programmer how to implement a language like Smalltalk. It is still one of the great books about a language implementation, and it still has a lot to teach us a lot about object-oriented languages.
But Goldberg didn't just write about Smalltalk; she was in the lab doing the work that created it. During the 1970s, she was one of the principal researchers at Xerox PARC. The team at PARC not only developed Smalltalk but also created and experimented with graphical user interfaces and other features of the personal computing experience that we all now take for granted.
Goldberg's legacy extends beyond the technical side of Smalltalk. She worked with Alan Kay to develop an idea of computing as a medium for everyone and a new way for young people to learn, using the computer as a dynamic medium. They described their vision in Personal Dynamic Media, a paper that appeared in the March 1977 issue of IEEE Computer. This was a vision that most people did not really grasp until the 1990s, and it inspired many people to consider a world far beyond what existed at the time. But this paper did not just talk about vision; it also showed their ideas implemented in hardware and software, tools that children were already using to create ideas. When I look back at this paper, it reminds me of one reason I admire Goldberg's work: it addresses both the technical and the social, the abstract and the concrete, idea and implementation. She and Kay were thinking Big Thoughts and also then testing them in the world.
(A PDF of this paper is currently available on-line as part of the New Media Reader. Read it!)
After leaving PARC, Goldberg helped found ParcPlace, a company that produced a very nice Smalltalk product suitable for corporate applications and CS research alike. The Intelligent Systems Lab I worked in as a grad student at Michigan State was one of ParcPlace's first clients, and we built all of our lab's software infrastructure on top of its ObjectWorks platform. I still have ObjectWorks on 3.5" floppies, as well as some of the original documentation. (I may want to use it again some day...)
Some academics view founding a business as antithetical to the academic enterprise, or at least as not very interesting, but Goldberg sees it as a natural extension of what computer science is:
The theoretical and practical knowledge embodied in CS is interesting as standalone study. But the real opportunity lies in equipping oneself to partner with scientists or business experts, to learn what they know and, together, to change how research or business is conducted.
(I found this quote as a sidebar in Women in Computing -- Take 2, an article in a recent issue of Communications of the ACM.)
I suppose that the women-don't-like-to-program crowd might point to Goldberg's career in industry as evidence that she prefers computing in its applied context to the hard-core technical work of computer science, but I don't think that is true. Her work on Smalltalk and real tools at PARC was hard-core technical, and her work at ParcPlace on Smalltalk environments was hard-core technical, too. And she has the mentality of a researcher:
Don't ask whether you can do something, but how to do it.
When no one knows the answer, you figure it out for yourself. That's what Goldberg has done throughout her career. And once she knows how, she does it -- both to test the idea and make it better, and to get the idea out into the world where people can benefit from it. She seems to like working on both sides of the divide. No, she would probably tell us that the divide is an artificial barrier of our own making, and that more of us should be doing both kinds of work.
When we are looking for examples of women who have helped invent computer science, we find researchers and practitioners. We find women working in academia and in industry, working in technical laboratories and in social settings where applications dominate theory. We don't have to limit our vision of what women can do in computing to any one kind of work or work place. We can encourage young women who want to be programmers and researchers, working on the most technical of advances. We can encourage young women who want to work out in the world, changing how people do what they do via the dynamic power of software. If you are ever looking for one person to serve as an example of all these possibilities, Adele Goldberg may be the person you seek.
I spent this morning with what seems like an old friend.
When we first moved here in 1992, we heard a lot about the 60 miles of recreational trails in the area, and what they meant for the quality of life we could have here. The system now spans more than 80 miles, and I have spent a lot of hours on most of them. I've walked and biked with my family there, but I've spent far more hours on the trails alone, running. Sometimes, I'm training for a race. Then, the trail is a work partner. Other times, I'm simply running, and the trail is more like a friend I share the quiet time with. Many of my favorite routes, including a 12-miler north of town and a 16-miler south, are run partly or entirely on trails.
My most frequent trail segment is a simple loop, 6.2 miles in length -- a cosmic accident of 10K for runners, to whom that distance has special significance. It was within a 1.5 miles of my old house, so I used it all the time. Being off my game since last May, though, I haven't had many opportunities to run it, because I either wasn't running or wasn't running enough to get me to the loop, around it, and back home. As I wrote last month, my mileage has been way down since November, while I struggled to get healthy. Not much call for a 6-mile loop when I was happy just to run three miles twice in a week!
Well, a couple of weeks back, I worked my way up to a 17-mile week capped with a 5-mile "long run". After a hiccup last week, I finished off an 18-mile week with a 6-mile run around my old friend. The curves and trees and water all seemed old and new at the same time. It was cloudy and cool, with an occasional remnant of an icy winter. My senses drank it in. A good day.
As much as I enjoyed running an old route today, over the last few weeks I have also been enjoying building new routes from our new house. One advantage of my recent bad health is that I have had to start with 3-mile and 3.5-mile runs. Were I in marathon shape, I wouldn't want to waste my time mapping out such short routes. Yet they are the foundation I need for my training. Even at the peak of preparing for a marathon, I like to do easy 3-milers on Monday, the day after my long runs. When I'm not training for a big race, I like to have a full complement of routes of all distances, so that I can run whatever I feel like on a given morning.
Beginning again -- again -- is hard. It is different from starting the first time. When I began training for my first marathon, I didn't know what I was getting myself into, really. Each new long distance run was a challenge, but I just kept plugging away. This time, I know what it feels like to be in top shape, ready to run fast or long on demand. Ready to take on anything. To run a mere six easy miles and feel like I am working hard -- not struggling, yet not quite comfortable -- well, in a way the challenge seems all the more daunting. Having conquered it once, can I do it again?
I think a lot about a couple of friends who are or were training for their first marathons. It is hard for them! They usually don't have the 10-15 miles/week foundation that I had when I started, so every step can feel like a chore. The fatigue and soreness are new and can feel insurmountable. When the first deep cold spell settled over us in December, one buddy set aside his ambition. He wasn't ready to face two opponents at once. All one can do is persevere. Eventually, everything comes together, and you feel like a runner.
I know that I don't face their challenge, but having already been there... This gives me a glimpse of what it must be like for an accomplished athlete who has to return from a debilitating injury. I know it's just a glimpse; I've never accomplished much as a runner other than to finish a few races and have some fun. But it is an interesting new challenge to struggle on a 3-, 5-, or 6-mile run, knowing what it's like not to struggle at that distance, or at any distance. Do I have what it takes?
I think so. Old friends and new will help me through.
Tim Bray talks about how photography is too easy to learn:
Quoting from About Photography (1949) by American photographer Will Connell (hat tip Brendan MacRae): "Every medium suffers from its own particular handicap. Photography's greatest handicap is the ease with which the medium as such can be learned. As a result, too many budding neophytes learn to speak the language too long before they have anything to say."
Programming doesn't seem to suffer from this problem! Comments to Bray's entry about books like "C for Dummies" notwithstanding, there are not many people walking around who think programming is too easy. Mark Guzdial has described the reaction of students taking a non-majors course with a computational economics theme when they found out they would have to do a little scripting in Python. Most people who do not already have an interest in CS express disdain for programming's complexity, or fear of it. No one likes to feel stupid. Perhaps worst of all, even students who do want to major in CS don't want to program.
We in the business seem almost to have gone out of our way to make programming hard. I am not saying that programming is or can be "easy", but we should stop erecting artificial barriers that make it harder than it needs to be -- or that create an impression that only really smart people can write code. People who have ideas can write. We need to extend that idea to the realm of code. We cannot make professional programmers out of everyone, any more than piano and violin lessons can make professional musicians out of everyone. But we ought to be able to do what music teachers can do: help anyone become a competent, if limited, practitioner -- and come to appreciate the art of programming along the way.
The good news is that we can solve this "problem", such as it is. As Guzdial wrote in another fine piece:
An amazing thing about computing is that there are virtually no ground rules. If we don't like what the activity of programming is like, we can change it.
We need to create tools that expose powerful constructs to novices and hide the details until later, if they ever need to be exposed. Scratch and Alice are currently popular platforms in this vein, but we need more. We also need to connect the ability to program with people's desires and interests. Scripting Facebook seems like the opportunity du jour that is begging to be grasped.
I'm happy to run across good news about programming, even if it is only the backhanded notion that programming is not too easy. Now we need to keep on with the business of making certain that programming is not too hard.
David Patterson wrote a Viewpoint column for the March 2009 issue of Communications on advising graduate students, paired with a column by Jeffrey Ullman. One piece of Patterson's advice applies to more than advising grad students: "You're a role model; act like one.":
I am struck from parenting two now-grown sons that it's not what you say but what you do that has lasting impact. I bet this lesson applies to your academic progeny. Hence, I am conscious that students are always watching what I do, and try to act in ways that I'd like them to emulate later.
For example, my joy of being a professor is obvious to everyone I interact with, whereas I hear that some colleagues at competing universities complain to their students how hectic their lives are.
I often worry about the message I send students in this regard. My life is more hectic and less fun with computer science since I became department head, and I imagine that most of the negative vibe I may give off is more about administration than academia. One time that I am especially careful about the image I project is when I meet with high school students who are prospective CS majors and their parents. Most of those encounters are scheduled in advance, and I can treat them almost like performances. But my interactions with current students on a daily basis? I'm probably hit-and-miss.
The idea that people will infer more from your deeds than your words is not new and does apply widely, to advisors, teachers, decision makers -- everyone, really. Anyone who has been a parent knows what Patterson means about having raised his sons. Long ago I marked this passage from Matthew Kelly's Building Better Families:
If you ask parents if they want their children to grow up to live passionate and purposeful lives they will say, "Absolutely!" But how many parents are living passionate and purposeful lives? Not so many.
Our example can set a negative tone or a positive tone. The best way to give children a zest for life is to live with zest and share your zest with them.
This applies to our students in class and in the research lab, too. My favorite passage in this regard comes not from Patterson's viewpoint but from The Wednesday Wars, which I quoted once before:
It's got to be hard to be a teacher all the time and not jump into a pool of clear water and come up laughing and snorting with water up your nose.
Through all my years in school, my best teachers jumped into the pool all the time and came up laughing and snorting with water up their noses. They wrote prose and code. They read about new ideas and wanted to try them out in the lab. Their excitement was palpable. Fun was part of the life, and that's what I wanted.
I hope I can embody a little of that excitement and fun as a faculty member to our students, as a father to my daughters. But some days, that is more of a challenge than others.
I spent most of the last four days of last week -- and nights -- digging out of the result of having lived 17 years in one house, as a moderate pack rat living with three major pack rats.
Remember that whole moving agile thing? Fuhgeddaboudit. The idea worked well for a few weeks. But then we encountered a problem everyone knows to avoid: the developers were the same people as the customers. When we got somewhere between 60% and 80% of our stuff moved, we reached something akin to a software prototype that offers most of the desired features. At that point, the customers went inexplicably AWOL. They were happy enough with the 80% solution.
Then came a long period of no measurable progress, no external motivation, and no Big Visible Chart to keep the developers honest.
Finally came the week of the closing on the sale of the old house. We were exceedingly lucky to have found buyers the first day the house was on the market and to have them want to close in a brisk five weeks. Hurray! ... except for the part about moving the rest of our stuff. We found ourselves in horrible crunch mode. The last 20% took 80% of the total move time. I worked around the clock for four days, stopping for classes and essential meeting. In the end, we just made it -- I, dead tired, with a bad cold, and a lot of stuff in boxes.
Why the title? After 17 years of saving things we "might need some day", we know the answer. We never did. We had boxes. Packing material. Textbooks, class notes. YAGNI. Really. I went from sentimental fool having a hard time tossing anything to pitching favored gifts and keepsakes like a disinterested pro. A few possessions rose above the newly-elevated threshold for what to keep, but not many. If I don't have a specific plan for using something in the next few weeks, it is gone. I have enough boxes and portfolios and a pile of notebooks and pads sufficient to outfit a medium-sized government agency. If I don't have a specific scenario for reminiscing over some memento, it too is gone. Sportsmanship trophies from 2nd-grade basketball leagues? I don't think so.
I ain't gonna need it. I trust that now. This is the best lesson for living more simply than I've ever received.
On Learning Curves, I read a lament about calculus students having a hard time putting their skills into practice on some basic word problems. This line stood out:
They can do the calculus. The algebra slays them.
Of late, our CS faculty have been discussing a programming corollary. Students have passed their intro programming course and a data structures course. They get to an intermediate programming course, or a programming languages course, or an AI course, where they learn some more advanced design idea or algorithm. They answer conceptual courses about the material on exams and do well. Then they try to write code... and hit a wall.
Sometimes a new programming language gets in the way, but sometimes not -- students are using a language they used for a year in the intro sequence. And whether it's a new language or an old one, the problems seem ticky-tack: semicolons, declarations, function calls.
They can talk about the advanced concepts, but simple programming tasks to implement the ideas slays them. The programming part looks like attention to detail to me, or effort spent to internalize basic grammar and vocabulary. One prof half-jokingly says his students have gone out of their way to forget what they already knew.
You don't really know programming unless you can write a program from a real problem, and not just a tightly-specified exercise designed by the instructor. And I'm not sure you can really know a concept -- not in the way that a computer scientist needs to know it -- unless you can write a program using it for a real problem. If syntax is in the way, you simply need to buckle down and learn the syntax.
I don't have any answers on this but thought it was interesting that a calculus prof is running into the same kind of problem.
Yesterday, I mentioned writing reports for a campus-wide Academic Program Assessment. While the process of gathering data and writing it up was laborious and, at times, stultifying, I did learn some things about our programs and department. Data can be illuminating. Feedback is good. Reflection is a worthwhile activity.
But collecting data, studying it, and crafting a story of feedback are time-consuming, and many people in my department and university think that doing so spends time that could be contributing to our substantive goals.
Of course getting feedback can and should contribute to the substantive goal of doing our jobs, and doing them better. The problem is pushing the working of collecting data and studying it out of the daily workflow and then making it an onerous and extended interruption of the workflow. Kent and Ward got something right when they talked about finding a way to work feedback -- rapid, automated, and as inexpensive as possible -- into the daily act of making something.
This post is a rerun of a previous post, or maybe two! But every once in a while I feel myself in a rerun mode, a rerun mood. Bureaucracy on one side of the process and cynicism on the other get in the way of changing how and when to gather and use organizational feedback more effectively. How can we get better? How do I get better?
Last week, I read this passage from Liz Keogh and took comfort from it:
Whatever we do with the story, in order to get feedback, it has to show something that the business can understand and on which they can give us feedback. If you can't get feedback, nobody cares. If nobody cares, it's not a story.
(If you're having problems getting feedback from your business, try delivering something.)
Perhaps one way to combat cynicism from people who have reason to be cynical is to craft a better story. Maybe I don't get feedback because the story I ask them to work on is not a story to them. Maybe I could get better or more feedback by delivering something.
When things don't go as well as I might hope, it is not always my fault. And when I share responsibility, it is not always only my fault. (I know -- I need to make a move away from the language of blame and find a way to think about making things better. Another of Liz's posts reminded me of that, too!)
But... All I can fix is myself, and what I do. Generally, trying to fix others does not work well, and even when it does, it doesn't make for an effective long-term strategy to move the team or the department forward. So, how can I do better?
I have spent nearly every working minute this week sitting in front of this laptop, preparing a bunch of documents for an "academic program assessment" that is being done campus-wide at my university. Unfortunately, that makes this week Strike Two.
This week: no SIGCSE for me.
The next pitch arrives at the plate in about a month... Will there be no ChiliPLoP for me?
That would be an inglorious Strike Three indeed. It would break my equivalent of DiMaggio's streak: I have never missed a ChiliPLoP. But budget rescissions, out-of-state travel restrictions, and work, work, work are conspiring against me. I intend to make my best effort. Say a little prayer.
I hope that you can survive my missing SIGCSE, as it will mean no reports from the front. Of course, you will notice two missing links on my 2008 report, so I do have some material in the bullpen!
Missing SIGCSE was tougher than usual, because this year I was to have been part of the New Teaching Faculty Roundtable on the day before the conference opened. I was looking forward to sharing what little wisdom I have gained in all my years teaching -- and to stealing as many good ideas as I could from the other panelists. Seeing all of the firepower on the roster of mentors, I have no doubts that the roundtable was a great success for the attendees. I hope SIGCSE offers the roundtable again next year.
Part of my working day today was spent in Cedar Rapids, an hour south of here. Some of you may recall that Cedar Rapids was devastated by flooding last summer, when much of the eastern part of the state was under 500-year flood waters. I surprised and saddened to see that so much of the downtown area still suffers the ill effects of the water. The public library is still closed while undergoing repair. But I was heartened to see a vibrant city rebuilding itself. A branch library has been opened at a mall on the edge of town, and it was buzzing with activity.
You know, having a library in the mall can be a good thing. It is perhaps more a part of some people's lives than a dedicated building in the city, and it serves as a nice counterpoint to the consumption and noise outside the door. Besides, I had easy access to excellent wireless service out in mall area even before the library opened, and easy access to all the food I might want whenever I needed to take a break. Alas, I really did spend nearly every working minute this week sitting in front of this laptop, so I worked my way right up to dinner time and a welcome drive home.
Two months from today is the Indy 500 Mini Marathon. That means I have nine weeks two work myself back up to 13 miles -- not racing shape, such as that is for me, just good enough shape to cover the distance without risking life or limb.
Given that my most recent news of two was managing two runs in a single week, even the lesser goal is a bit daunting. The good news is that I ran three times the week before last and four times last week. Those four runs totaled just a bit less than a half-marathon: 13 miles even. Yet I ran four times in a week for the first time since October. Hurray!
I'll set as aggressive an ascent as I can manage over the next couple of months, raising my long run by a mile or two each week. This is what I have in mind: 5, 6, 8, 5, 8, 10, 12, 10, and then the half. Dropping back to 5 one week helps the body incorporate the mileage and recover a bit. I can probably get with nothing more than a 10-mile long run, if that is necessary. But if I can manage a 12-miler, I'd like to, for my confidence and sanity before the race.
The overriding consideration will be health, trying to build back up without a recurrence of the symptoms that have gotten in the way since, oh, last May 2. What an anniversary race that will be. The last two weeks have left me hopeful but wary. I don't yet feel quite right, but I feel better than I have in a while.
At least the weather is beginning to turn a bit. Spring is in the offing. Though we had some cold weather over the weekend, the sun has moved higher in the sky and is lasting longer. Today, the outside looks almost as nice as the sun day in the photo above, taken by one of my workshop colleagues at SugarLoafPLoP 2004. 4 degrees of latitude below the equator creates a different set of conditions for running than most days in Iowa, yet in the end it is all the same: accept the challenge offered by today, and see where you can go. In Fortaleza that day, the challenge was a hot sun and a powerful humidity. The run was wonderful. I can only hope for runs as nice over the next two months.