September 01, 2014 3:17 PM
Back to the Beginning
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.
August 30, 2014 7:43 AM
A Monad Sighting in Pop Literature
Lab experiments are invaluable in the hard sciences, in part because neutrinos and monads don't change their behavior when they are being watched; but humans do.
Several things ran through my mind when I read this sentence.
- "Monads don't change their behavior when watched." Wow. The authors of this book must know a little functional programming.
- Monads mentioned in the same sentence as neutrinos, which are fundamental particles of the universe? Oh, no. This will only make the smug functional programming weenies more smug.
- Monads are part of the "hard sciences"? These authors really do get functional programming!
- This sentence appears in a chapter called "The Three Hardest Words in the English Language". That joke writes itself.
- Maybe I shouldn't be surprised to see this sentence. The book called Think Like a Freak.
I kid my monad-loving friends; I kid. The rest of the book is pretty good, too.
August 19, 2014 1:49 PM
The Universal Justification
Because we need it to tell better stories.
Ethan Zuckerman says that this is the reason people are addicted to big data, quoting Macej Ceglowski's wonderful The Internet with a Human Face But if you look deep enough, this is the reason that most of us do so many of the things we do. We want to tell better stories.
As I teach our intro course this fall, I am going to ask myself occasionally, "How does what we are learning today help my students tell a better story?" I'm curious to see how that changes the way I think about the things we do in class.
August 16, 2014 10:19 AM
Channeling Virginia Woolf
In her diary, Woolf once secured in words a state of mind that has waylaid me recently.
Still if one is Prometheus, if the rock is hard and the gadflies pungent, gratitude, affection, none of the nobler feelings have sway. And so this August is wasted.
And yet hope remains. August is but half past.
(From an entry dated Tuesday, August 18, 1921, in A Writer's Diary.)
July 30, 2014 1:04 PM
The Reach of a MOOC
Distributed computing, OOP, and patterns guru Doug Schmidt recently posted on Facebook a statistical recap of his summer MOOC on pattern-oriented software architectures for mobile devices and cloud computing. Approximately 80,000 people signed up for the course, 40,000 people showed up, and 4,000 people completed the course in a meaningful way (taking automated quizzes and possibly doing peer-graded programming assignments). So that's either a 5% completion rate for the course, or 10%, depending on which standard you prefer.
A lot of folks complain that the reach of MOOCs is muted by their notoriously low completing rates. But Schmidt puts the numbers into perspective:
... I've taught ~1,000 students at Wash U., UC Irvine, and Vanderbilt in the past 20 years, so regardless of the completion *rate* the opportunity to reach > 4,000 students and teach them about patterns and frameworks for concurrent programming in Java and Android is pretty cool!
Schmidt has a lot of knowledge and experience to share. His MOOC shared it with an awful lot of people in one offering.
My department has not attempted a "massive" on-line course yet, though a few of our faculty did take a small first step last month. As Mark Guzdial lamented a few months ago, Google required that all of its CS4HS summer workshops be offered on-line. A few of my colleagues, led by Ben Schafer, have taught CS4HS workshops for the last five years, reaching in the ballpark of 20-25 teachers from northeast Iowa in each of the first four. As reported in the department's own Facebook post, this year the course enrolled 245 teachers from thirty-nine states and Puerto Rico. I haven't seen final numbers for the workshop yet, but just after it ended Ben reported good participation and positive evaluations from the teachers in the course.
I don't know yet what I think about MOOCs. The trade-offs are numerous, and most of my teaching experience is in smaller, more intimate settings that thrive on individual relationships with students. But I can't deny the potential reach for MOOCs to reach so many people and to provide access to valuable courses to people who otherwise likely could never attend them.
On a lighter note, the first comment in response to Schmidt's Facebook post is my favorite in a while:
I just loaded the dishwasher. Our jobs are so similar! Crazy, eh?
Don't worry, Kristie. Sometimes, I look at all the amazing thing Doug does and feel exactly the same.
July 28, 2014 1:00 PM
Sometimes, You Have To Speak Up For Yourself
Wisdom from the TV:
"Whatever happened to humility, isn't that a virtue or something?"
"One of the highest. People in power are always saying so."
It is worth noting that one of the antonyms of "humble" is "privileged".
This passage apparently occurs in an episode of Orange Is The New Black. I've never seen the show, but the exchange is quoted in this discussion of the show.
I just realized how odd it is to refer to Orange Is The New Black as a TV show. It is Netflix original series, which shows up on your TV only if you route your Internet viewing through that old box. Alas, 30- and 60-minute serialized shows have always been "TV" to me. I'm caught in the slipstream as our dominant entertainment media change forms.
July 21, 2014 10:52 AM
Wesley's Quoted Quote
My recent post Burn All Your Sermons was triggered by a quote taken out of context. Theologian John Wesley did not say:
Once in seven years I burn all my sermons...
"Once in seven years I burn all my sermons..."
Those "" make all the difference. Wesley wasn't saying that he himself burns all his sermons every seven years; he was talking about the practice doing so. Imagine the assistant of Wesley who, upon seeing this passage in the theologian's diary, burned all of Wesley's old sermons in an effort to ingratiate himself with the boss, only later to find out that Wesley very much intended to use them again. Fiery furnace, indeed.
This sort of indirection isn't important only for human communication. It is a key idea in computing. I wrote a blog post last year about such quotations and how this distinction is an important element in Jon Udell's notion of "thinking like the web". Thinking like the web isn't always foreign to the way most of us already think and work; sometimes it simply emphasizes a particular human practice that until now has been less common.
Studying a little computer science can help, though. Programmers have multiple ways of speaking indirectly about an action such as "burn all the sermons". In Scheme, I might express the program to burn all the sermons in a collection as:
We can quote this program, in much the same way that the "" above do, as:
This is actually shorthand for (quote (burn sermons)). The result is a piece of data, much like Wesley's quotation of another person's utterance, that we can manipulate a variety of ways.
This sort of quotation trades on the distinction between data and process. In a post a few years back, I talked a bit about how this distinction is only a matter of perspective, that at a higher level data and program are two sides of the same coin.
However, we can also "quote" our sermon-burning program in a way that stays on the side of process. Consider this program:
(lambda () (burn sermons))
The result is a program that, when executed, will execute the sermon-burning program. Like the data version of the quote, it turns the original statement into something that we can talk about, pass around as a value, and manipulate in a variety of ways. But it does so by creating another program.
This technique, quite simple at its heart, plays a helpful role in the way many of computer language processors work.
Both techniques insert a level of indirection between a piece of advice -- burn all your sermons -- and its execution. That is a crucial distinction when we want to talk about an idea without asserting the idea's truth at that moment. John Wesley knew that, and so should we.
July 17, 2014 10:00 AM
A New Commandment
... I give unto you:
Our first reaction to any comrade, any other person passionate about and interested in building things with computers, any human crazy and masochistic enough to try to expand the capabilities of these absurd machines, should be empathy and love.
Courtesy of Britt Butler.
I hope to impart such empathy and love to my intro students this fall. Love to program, and be part of a community that loves and learns together.
July 16, 2014 2:11 PM
Burn All Your Sermons
Marketers and bridge players have their Rules of Seven. Teachers and preachers might, too, if they believe this old saw:
Once in seven years I burn all my sermons; for it is a shame if I cannot write better sermons now than I did seven years ago.
I don't have many courses in which I lecture uninterrupted for long periods of time. Most of my courses are a mixture of short lectures, student exercises, and other activities that explore or build upon whatever we are studying. Even when I have a set of materials I really like, which have been successful for me and my students in the past, I am forever reinventing them, tweaking and improving as we move through the course. This is in the same spirit as the rule of seven: surely I can make something better since the last time I taught the course.
Having a complete set of materials for a course to start from can be a great comfort. It can also be a straitjacket. The high-level structure of a course design limits how we think about the essential goals and topics of the course. The low-level structure generally optimizes for specific transitions and connections, which limits how easily we can swap in new examples and exercises.
Even as an inveterate tinkerer, I occasionally desire to break out of the straitjacket of old material and make a fresh start. Burn it all and start over. Freedom! What I need to remember will come back to me.
The adage quoted above tells us to do this regularly even if we don't feel the urge. The world changes around us. Our understanding grows. Our skills as a writer and storyteller grow. We can do better.
Of course, starting over requires time. It's a lot quicker to prep a course by pulling a prepped course out of an old directory of courses and cleaning it up around the edges. When I decide to redesign a course from bottom up, I usually have to set aside part of a summer to allow for long hours writing from scratch. This is a cost you have to take into account any time you create a new course.
Being in computer science makes it easier to force ourselves to start from scratch. While many of the principles of CS remain the same across decades, the practices and details of the discipline change all the time. And whatever we want to say about timeless principles, the undergrads in my courses care deeply about having some currency when they graduate.
In Fall 2006, I taught our intro course. The course used Java, which was the first language in our curriculum at that time. Before that, the last time I had taught the course, our first language was Pascal. I had to teach an entirely new course, even though many of the principles of programming I wanted to teach were the same.
I'm teaching our intro course again this fall for the first time since 2006. Python is the language of choice now. I suppose I could dress my old Java course in a Python suit, but that would not serve my students well. It also wouldn't do justice to the important ideas of the course, or Python. Add to this that I am a different -- and I hope better -- teacher and programmer now than I was eight years ago, and I have all the reasons I need to design a new course.
So, I am getting busy. Burn all the sermons.
Of course, we should approach the seven-year advice with some caution. The above passage is often attributed to theologian John Wesley. And indeed he did write it. However, as is so often the case, it has been taken out of context. This is what Wesley actually wrote in his journal:
Tuesday, September 1.--I went to Tiverton. I was musing here on what I heard a good man say long since--"Once in seven years I burn all my sermons; for it is a shame if I cannot write better sermons now than I could seven years ago." Whatever others can do, I really cannot. I cannot write a better sermon on the Good Steward than I did seven years ago; I cannot write a better on the Great Assize than I did twenty years ago; I cannot write a better on the Use of Money, than I did nearly thirty years ago; nay, I know not that I can write a better on the Circumcision of the Heart than I did five-and-forty years ago. Perhaps, indeed, I may have read five or six hundred books more than I had then, and may know a little more history, or natural philosophy, than I did; but I am not sensible that this has made any essential addition to my knowledge in divinity. Forty years ago I knew and preached every Christian doctrine which I preach now.
Note that Wesley attributes the passage to someone else -- and then proceeds to deny its validity in his own preaching! We may choose to adopt the Rule of Seven in our teaching, but we cannot do so with Wesley as our prophet.
I'll stick with my longstanding practice of building on proven material when that seems best, and starting from scratch whenever the freedom to tell a new story outweighs the value of what has worked for me and my students in the past.
July 15, 2014 3:19 PM
Ambiguous Questions and Wrong Answers
Pianist James Boyk recently shared a story about mathematician Andrew Gleason with me. Boyk had studied a bit with Gleason, who was known for his work in cryptography and in helping to solve Hilbert's fifth problem. Gleason also had a strong interest in early math education. Once, after observing first-grade math teaching for some weeks, Gleason said:
I never saw a kid give a wrong answer. I heard a lot of ambiguous or erroneous questions, but never a wrong answer.
As Boyk told me, there's a lesson in this attitude for everyone. So often in my own courses, I start to mark a student's answer as incorrect, step back, and realize that the question itself was ambiguous. The student had given a correct answer -- only to a question different than the one I had in my mind.
Not all my questions are ambiguous or erroneous, of course. Sometimes the student does give an incorrect answer. For a while now, I've been trying to retrain my mind to think in terms of incorrect answers rather than wrong answers. Yes, these words are synonyms, but their connotations differ. The meaning of "incorrect" is usually limited to the objective sense of being not in accordance with fact or standards. "wrong" has a wider meaning that also can include being immoral or dishonest. Those words seem a bit too judgmental to be applied to my students' sorting algorithms and Scheme programs.
In the case of erroneous answers, I find I'm usually more effective if I focus on the factual incorrectness of an answer. What misconception or missing piece of knowledge led the student to this conclusion? How can I help the student recognize this flaw in the reasoning and reason more accurately in the future?
That seems to be the big lesson of Gleason's comment: to keep the teacher's focus on how a student's answer is the correct answer, given what he or she knows at a given point in time. The teacher's job is to ask better questions and lead students to a better state of knowing and doing.