I saw a commercial recently for one of those on-line schools no one has ever heard of. In it, a non-traditional student with substantial job experience said, "At [On-Line U.], I can take classes I control."
I understand a desire for control, especially given the circumstances in which so many people go to university now. Late twenties or older, a family, a house, bills to pay. Under such conditions, school becomes a mercenary activity: get in, get a few useful skills and a credential, get out. Maximize ROI; minimize expenses.
In comparison, my years studying at a university were a luxury. I went to college straight out of high school, in a time with low tuition and even reasonable room and board. I was lucky to have a generous scholarship that defrayed my costs. But even my friends without scholarships seemed more relaxed about paying for school than students these days. It wasn't because Mom and Dad were picking up the tab, either; most of my friends paid their own way.
The cost was reasonable and as a result, perhaps, students of my era didn't feel quite the same need to control all of their classes. That is just as well, because we didn't have much control, nor much bargaining power to change how our professors worked.
What a fortunate powerlessness that was, though. In most courses, I encountered creative, intelligent professors. Once a year or so, I would walk into a course with rather pedestrian goals only to find that the professor had something different in mind, something unimagined, something wonderful. If naive, twenty-year-old Eugene had had control of all his courses, he would likely have missed out on a few experiences that changed his life.
What a great luxury it was to surrender control for eleven weeks and be surprised by new knowledge, ideas, and possibilities -- and by the professors who made the effort to take me there.
I know was lucky in a lot of ways, and for that I am thankful. I hope that our inability or unwillingness to keep public university affordable doesn't have as an unintended casualty the wonderful surprises that can happen in our courses.
This passage comes from an article at LessWrong about making beliefs "pay rent" by holding them accountable for the experiences they entail:
It is a great strength of Homo sapiens that we can, better than any other species in the world, learn to model the unseen. It is also one of our great weak points. Humans often believe in things that are not only unseen but unreal.
Our students bring this double-edged sword to the classroom with them.
Students seem able to learn important ideas even when teachers present the ideas poorly, or inconsistently, or confusingly. I probably don't want to know how often I depend on this good fortune when I teach...
At the same time, students can build models that are flatly untrue. This isn't surprising. When we draw conclusions from incomplete evidence and examples, we will occasionally go astray. The search space in which students work is vast; it is remarkable that they don't go astray more often.
Teachers experience both edges of the sword. Students model the unseen and, for the most part, the model the build is invisible to us. When is it an accurate model?
One of the biggest challenges for teachers is to bring both of the unseens closer to the surface.
The second of these is what makes face-to-face instruction and one-on-one interaction so powerful. We bring students' models to the surface most effectively in the ways we discuss ideas with them. Our greatest opportunities to discuss come from asking students to build something and then discussing with them both the product and the process of making it.
The more you produce and the more needs you meet, the more freedom you earn.
As Seth Godin says, it's fun to be (only) a consumer, but in the long run, smart producers win. Knowing how to produce solutions for yourself and others is the first step to freedom. Actually making things is the second.
This morning, I tweeted:
Pretty sure I could build a git-based curriculum management system in two weeks that would be miles better than anything on the market now.
Yes, I know that it is easy to have ideas, and that carrying an idea through to a product is the real challenge. At least I don't just need a programmer...
My tweet was the result of temporary madness provoked by yet another round of listening to non-CS colleagues talk about one of the pieces of software we use on campus. It is a commercial product purchased for one task only, to help us manage the cycle of updating the university catalog. Alas, in its current state, it can handle only one catalog at a time. This is, of course, inconvenient. There are always at least two catalogs: the one in effect at this moment, and the one in progress of being updated. That doesn't even take into account all of the old catalogs still in effect for the students who entered the university when they were The Catalog.
Yes, we need version control. Either the current software does not provide it, or that feature is turned off.
The madness arises because of the deep internal conflict that occurs within me when I'm drawn into such conversations. Everyone assumes that programs "can't do this", or that the programmers who wrote our product were mean or incompetent. I could try to convince them otherwise by explaining the idea of version control. But their experience with commercial software is so uniformly bad that they have a hard time imagining I'm telling the truth. Either I misunderstand the problem, or I am telling them a white lie.
The alternative is to shake my head, agree with them implicitly, and keep thinking about how to teach my intro students how to design simple programs.
I'm convinced that a suitable web front-end to a git back end could do 98% of what we need, which is about 53% more than either of our last two commercial solutions has done for us.
Maybe it's time for me to take a leave of absence, put together a small team of programmers, and do this. Yes, I would need a team. I know my limitations, and besides working with a few friends would be a lot more fun. The current tools in this space leave a lot of room for improvement. Built well and marketed well, this product would make enough money from satisfaction-starved universities to reward everyone on the team well enough for all to retire comfortably.
Maybe not. But the idea is free the taking. All I ask is that if you build it, give me a shout-out on your website. Oh, and cut my university a good deal when we buy your software to replace whatever product we are grumbling about when you reach market.
All students should learn to program? Not so fast, says Larry Cuban in this Washington Post blog entry. History, including the Logo movement, illustrates several ways in which such a requirement can fail. I've discussed Cuban's article with a couple of colleagues, and all are skeptical. They acknowledge that he raises important issues, but in the end they offer a "yeah, but...". It is easy to imagine that things are different now, and the result will be similarly different.
I am willing to believe that things may be different this time. They always are. I've written favorably here in the past of the value of more students learning to program, but I've also been skeptical of requiring it. Student motivations change when they "have to take that class". And where will all the teachers come from?
In any case, it is wise to be alert to how efforts to increase the reach of programming instruction have fared. Cuban reminds us of some of the risks. One line in his article expresses what is, to my mind, the biggest challenge facing this effort:
Traditional schools adapt reforms to meet institutional needs.
Our K-12 school system is a big, complex organism (actually, fifty-one of them). It tends to keep moving in the direction of its own inertia. If a proposed reform fits its needs, the system may well adopt it. If it doesn't, but external forces push the new idea onto system, the idea is adapted -- assimilated into what the institution already wants to be, not what the reform actually promises.
We see this in the university all the time, too. Consider accountability measures such as student outcomes assessment. Many schools have adopted the language of SOA, but rarely do faculty and programs change all that much how they behave. They just find ways to generate reports that keep the external pressures at bay. The university and its faculty may well care about accountability, but they tend to keep on doing it the way they want to do it.
So, how can we maximize the possibility of substantive change in the effort to teach more students how to program, and not simply create a new "initiative" with frequent mentions in brochures and annual reports? Mark Guzdial has been pointing us in the right direction. Perhaps the most effective way to change K-12 schools is to change the teachers we send into the schools. We teach more people to be computing teachers, or prepare more teachers in the traditional subjects to teach computing. We prepare them to recognize opportunities to introduce computing into their courses and curricula.
In this sense, universities have an irreplaceable role to play in the revolution. We teach the teachers.
Big companies can fund programs such as code.org and help us reach younger students directly. But that isn't enough. Google's CS4HS program has been invaluable in helping universities reach current K-12 teachers, but they are a small percentage of the installed base of teachers. In our schools of education, we can reach every future teacher -- if we all work together within and across university boundaries.
Of course, this creates a challenge at the meta-level. Universities are big, complex organisms, too. They tends to keep moving in the direction of their own inertia. Simply pushing the idea of programming instruction onto system from the outside is more likely to result in harmless assimilation than in substantive change. We are back to Cuban's square one.
Still, against all these forces, many people are working to make a change. Perhaps this time will be different after all.
If you are an engineer or faculty member thinking about moving into administration, you should read A Disclosure an essay by Rands. It is the best short treatment of "becoming a manager" I've read and is worth more than a stack of similarly-themed books from the business shelf in the bookstore.
I have never been an engineer per se. I was a faculty member: a programmer, teacher, and scientist. I built things in order to learn cool stuff, and then figured out how to teach my students about that same stuff. I came to management nine years ago when we needed a new department, via a blend of two of the paths Rands describes: I decided that I could be a better department head than our acting head, who was helping as a stand-in from another department, and there were no other reasonable choices at the time.
Whether I have been a good enough department head is open for discussion. This is a difficult job, or at least different enough from I used to do that it seems difficult. Re-reading this blog today reminds me that I should re-visit my decision occasionally. There may well be other reasonable choices now, and my decision may have changed.
How do you know that the job is different, that you are living in a different world now? Easy:
This sensation will appear at the end of the day when you ask, "What did I build today?" The answer will be a troubling, "Nothing". The days of fixing ten bugs before noon are gone. You're no longer going to spend the bus ride home working on code; you're going to be thinking hard about how to say something important to someone who doesn't want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting... something.
Before I became head, I never knew how many hours I would spend thinking hard about how to say something important to someone in a way that communicates effectively without misleading the person, confusing the person, or hurting the person's feelings. And, yes, sometimes people don't want to hear what I have to say.
The paragraph I quote is typical but not unique. Each week, I live some part of nearly every paragraph in this blog. The constant challenge for the engineer- or faculty member-turned-manager is, "Is this what makes you happiest and most effective?"
I regret missing the conference this year. I've been a regular attendee over the years and much enjoyed last year's edition. But it's probably just as well that the tickets sold out before I bought mine. My intro course has kept me pedaling full speed since school started, and I would have regretted missing a lab day and a class session just as we are getting to the meat of the course. I followed along with the conference on Twitter as time permitted.
The video titles foreshadow the usual treasure trove of Strange Loop content. It would be easier to list the talks I don't want to watch than the ones I do. A few I'll watch early on include Stephen Kell's "Liberating the Smalltalk Lurking in C and Unix", Stefanie Schirmer's "Dynamic Programming At Ease", Mark Allen's "All Of This Has Happened Before, and It Will All Happen Again", Julia Evans's "You Can Be a Kernel Hacker!", and Michael Nygard's "Simulation Testing".
An underrated advantage of actually attending a conference is not being able to be in two places at one time. Having to make a choice is sometimes a good thing; it helps us to preserve limited resources. The downside to the wonderfulness of having all the videos available on-line, for viewing at my leisure, is that I want to watch them all -- and I don't have enough leisure!
I ran across this paragraph in an essay about things you really need to learn in college:
Indeed, you should view the study of mathematics, history, science, and mechanics as the study of archetypes, basic patterns that you will recognize over and over. But this means that, when you study these disciplines, you should be asking, "what is the pattern" (and not merely "what are the facts"). And asking this question will actually make these disciplines easier to learn.
Even in our intro course, I try to help students develop this habit. Rather than spending all of our time looking at syntax and a laundry list of language features, I am introducing them to some of the most basic code patterns, structures they will encounter repeatedly as they solve problems at this level. In week one came Input-Process-Output. Then after learning basic control structures, we encountered guarded actions, range tests, running totals, sentinel loops, and "loop and a half". We encounter these patterns in the process of solving problems.
While they are quite low-level, they are not merely idioms. They are patterns every bit as much as patterns at the level of the Gang of Four or PoSA. They solve common problems, recur in many forms, and are subject to trade-offs that depend on the specific problem instance.
They compose nicely to create larger programs. One of my goals for next week is to have students solve new problems that allow them to assemble programs from ideas they have already seen. No new syntax or language features, just new problems.
Laurie Penny describes one effect of so many strands of modern life converging into the use of a single device:
That girl typing alone at the internet café might be finishing off her novel. Or she might be breaking up with her boyfriend. Or breaking into a bank. Unless you can see her screen, you can't know for sure. It's all just keystrokes.
Some of it is writing in ways we have always written; some it is writing in ways only recently imagined. Some of it is writing for a computer. A lot of it is writing.
(Excerpt from Why I Write.)
I had never heard of the "suffocating gerbils" problem until I ran across this comment in a Lambda the Ultimate thread on mixing declarative and imperative approaches to GUI design. Peter Van Roy explained the problem this way:
A space rocket, like the Saturn V, is a complex piece of engineering with many layered subsystems, each of which is often pushed to the limits. Each subsystem depends on some others. Suppose that subsystem A depends on subsystem B. If A uses B in a way that was not intended by B's designers, even though formally B's specification is being followed by A, then we have a suffocating gerbils problem. The mental image is that B is implemented by a bunch of gerbils running to exhaustion in their hoops. A is pushing them to do too much.
I first came to appreciate the interrelated and overlapping functionality of engineered subsystems in graduate school, when I helped a fellow student build a software model of the fuel and motive systems of an F-18 fighter plane. It was quite a challenge for our modeling language, because the functions and behaviors of the systems were intertwined and did not follow obviously from the specification of components and connections. This challenge motivated the project. McDonnell Douglas was trying to understand the systems in a new way, in order to better monitor performance and diagnose failures. (I'm not sure how the project turned out...)
We suffocate gerbils at the university sometimes, too. Some functions depend on tenure-track faculty teaching occasional overloads, or the hiring of temporary faculty as adjuncts. When money is good, all is well. As budgets tighten, we find ourselves putting demands on these subsystems to meet other essential functions, such as advising, recruiting, and external engagement. It's hard to anticipate looming problems before they arrive in full failure; everything is being done according to specification.
Now there's a mental image: faculty gerbils running to exhaustion.
If you are looking for something new to read, check out some of Van Roy's work. His Concepts, Techniques, and Models of Computer Programming offers all kinds of cool ideas about programming language design and use. I happily second the sentiment of this tweet:
Note to self: read all Peter Van Roy's LtU comments in chronological order and build the things that don't exist yet: http://lambda-the-ultimate.org/user/288/track?from=120&sort=asc&order=last%20post
There are probably a few PhD dissertations lurking in those comments.
Stephen Ramsey wrote The Mythical Man-Finger, in defense of an earlier piece on the virtues of the command line. The gist of his argument is this:
... the idea that language is for power users and pictures and index fingers are for those poor besotted fools who just want toast in the morning is an extremely retrograde idea from which we should strive to emancipate ourselves.
Ramsay is an English professor who works in digital humanities. From the writings posted on his web site, it seems that he spends nearly as much time teaching and doing computing these days as he spends on the humanities. This opens him to objections from his colleagues, some of whom minimize the relevance of his perspective for other humanists by reminding him that he is a geek. He is one of those experts who can't see past his own expertise. We see this sort of rhetorical move in tech world all the time.
I think the case is quite the opposite. Ramsay is an expert on language. He knows that language is powerful, that language is more powerful than the alternatives in many contexts. When we hide language from our users, we limit them. Other tools can optimize for a small set of particular use cases, but they generally make it harder to step outside of those lines drawn by the creator of the tools: to combine tasks in novel ways, to extend them, to integrate them with other tools.
Many of my intro students are just beginning to see what knowing a programming language can mean. Giving someone language is one of the best ways to empower them, and also a great way to help them even see what is possible.
Just this week I learned that Jon Sticklen, my PhD advisor, has moved to Michigan Tech to chair its Department of Engineering Fundamentals. As I recall, Michigan Tech focuses much of its effort on undergraduate engineering education. This makes it a good fit for Jon, who has been working on projects in engineering education at Michigan State for a number of years now, with some success. I wish him and them well.
By the way, if you can handle a strong winter, then Tech can be a great place to live. The upper peninsula of Michigan is stunning!
August was quiet on my blog only because it was anything but quiet elsewhere. The department office had its usual August business plus a couple of new challenges thrown in. I spent one day on jury duty, one day in retreat with fellow department heads, and one day on a long bike ride. My older daughter was home for a few days before heading back to college for her senior year, and my younger daughter was preparing to leave for college for the first time.
On top of that, I am teaching our intro course this fall. I have not taught intro since the fall of 2006, when I introduced media computation into our Java track. Before that we have to go back to the late 1990s to find me in front of a classroom full of students embarking on their first programming experience. I'm excited and a little apprehensive. There is great opportunity in helping students lay the foundation for the rest of their CS coursework. But there is also great risk. For the most part, these students have never worked with a floating-point number or a variable or an assignment statement, at least in the context of a programming language. How badly might I lead them astray?
We now teach Python in this track. I could have used media comp as our organizing theme again, but the instructors who have been teaching in this track for the last few years have moved to a data manipulation them, using a textbook by Bill Punch and Rich Enbody. I decided to do the same. There is no sense in me disrupting the flow of the track, especially with the likelihood that I won't teach the course again in the spring. (In the interest of full disclosure, I told my students that Bill was one of my mentors in grad school at Michigan State.)
The first week of class went well. As expected, the students reminded me how different teaching intro can be. There are so many ways for novices to interpret so many things... Type a simple expression or two into the Python shell, ask them what they think,and find out for yourself!
Every teacher knows that the first day of class shatters any illusion we might have of teaching the perfect course. Such illusions are more common for me when I teach a course for the first time, or the first time in a long while. The upside of shattering the illusion is that I can move on to the daily business of getting better.
At the end of our first lab session, I walked with one student as he was leaving the room. He had asked a few questions during the exercise. I asked how he felt, now that he had completed successfully his first lab as a CS major. "I am excited and scared," he said. "Scared has been keeping me away from computer science, but I know I have to try. I'm excited."
I know exactly he how feels. I'm apprehensive, not in fearing failure or catastrophe, but in being aware that I must remain vigilant. When we teach, we affect other peoples' lives. Teaching a first course in the discipline, introducing students to a new set of ideas and way of thinking, is a multiplier on this effect. I owe it to these students to help them overcome their fears and realize their excitement.