Fostered by Make magazine and Boingboing.net, members of the current generation of hackers are as likely to call themselves “makers” and cite a background in woodworking or welding as tantamount to their skills with computers. The common principle of making, rather than buying, things guides this technologically bent, do-it-yourself culture, which has blown up in the form of community spaces across the U.S. and Europe over the past two years…”That speaks to what we’re all about,” Storey says. “Making cool stuff out of nothing.”

via Freeside Atlanta makes space for local hackers.

I was intrigued by the community of hackers described in this article who “hack” more than computers.  But it’s the very last line of the article that really caught my eye.

“Making cool stuff out of nothing.”  That’s the essence of what we do in computing.  The ACM-WGBH study of the image of computing highlighted how attractive that aspect of our field is for students.  We need to figure out how to highlight that image in our classes: “Making, rather than buying” and “Making cool stuff out of nothing.”

“With my undergraduates, the hardest thing to teach them to do is make an argument, support that argument with evidence and bend and move and evolve,” said Susan Herbst, a professor of public policy at Georgia Tech. “Debate is an accelerated way to teach students to do that.”

via High school debate: We all need a lesson in it — chicagotribune.com.

I am actually teaching two educational technology classes this semester, one for undergraduates and one for graduates.  They happen to meet in the same room at the same time, which means it’s basically one, large, large-variance course.  I have undergraduates in Computer Science and Computational Media; and MS students in Computer Science, Digital Media, and HCI; and even some PhD students.  I’m teaching this class around argumentation.

• In Phase 1 of the class, I gave them a proposition, had them read papers about that proposition, then they wrote me a paper making an argument. The proposition was: “Computing creates an opportunity to program, and learning to program creates an opportunity to learn other things better.”  We read Seymour Papert and Alan Kay, Sharon Carver and Elliot Soloway.
• In Phase II, I gave them propositions and papers, and they picked proposition (in teams) then presented it and wrote a paper with the argument.
• In Phase III (right now), they invented the proposition and I helped them with the papers.  They’re presenting for the rest of the term, then owe me a paper at the end.  One group last Thursday defended “The choice of computer language used in CS1 courses has no great impact on the ability of computer science majors to perform in follow-on computer science courses” and another team defended “Instructional video materials can be used to teach declarative and procedural knowledge about computer science, creating expanded opportunities for learning with limited technological investment.”

My reason for this structure is that I’m trying to avoid graduate students coming to qualifying exams unable to argue a position. Since we’re a research institution, all students should learn a critical research skill — how we make an argument based on research literature.  Even for the undergraduates, it’s worthwhile for them to learn in terms of argument, evidence, and story.

The presentations have been so-so.  They sometimes work really hard to involve the audience and present interesting material.  However, in so doing, they often miss the argument.  The argument comes through better in the papers.

All the papers have been readable, but few really present an argument.  My undergraduates don’t write to an audience.  They all spend way too much time setting up their story and making flowery claims about the importance of education and of their proposition — things that make it easy to hit the 10-12 page expected length but don’t really speak to me or their classmates as an informed audience.  Surprising to me, only my Masters students from our Digital Media program really know how to make an argument. They are really careful in their analysis, defining their terms, and making their claims. Even PhD students skip basic steps like defining terms.  One recent team completely ignored half their proposition.

I’m not really surprised.  I spend much of my writing time with my PhD students trying to teach them to write to a story and to defend their argument.  I know that my advisor, Elliot Soloway, spent a lot of effort helping me to tell stories in my papers.  I’ll bet most advisors do.  So while I might wish for better from our undergraduates, I don’t expect more than I’m seeing with regards to writing and argumentation ability. The article referenced above is making a stronger point — that debate is a critical skill, and we should teach it earlier. I think that Susan Herbst’s comment above is particularly critical for our graduate students.  They must know how to make an argument, to engage in debate, to tell a story with evidence.

The role that debate (as Susan refers to it — making an argument, using evidence, telling a story) plays in learning is important in computing education, too, in the sense of the blue-collar vs. white-collar distinction made in the last blog post.  It’s not clear how much you learn about computer science just by programming.  It’s clear that you can learn a lot of computer science by programming, if you bring a lot of knowledge to the task in the first place.  If you don’t know what you’re doing, if you don’t understand grammar and the notional machine, you work to correct bugs with random walks of semi-colons.  If you know what you’re doing, a new bug can become an exploration that leads to new learning.  In my experience, learning from the activity of constructing and designing only really works when there is a base of knowledge to begin with.  It’s hard to start from programming.

The base of knowledge to learn from construction and design is akin to the elaborated knowledge necessary to engage in a debate.  Then, when you have a bug, it’s a challenge to your understanding, and you have to “bend and move and evolve.”  How do we develop that elaborated knowledge in computer science students?  We lecture at them and have them read a book.  Is that enough?  Does reading a book teach you to have the knowledge of a debater?  What is the analogy of debate for computer science students? How do we help computer science students develop rich understanding, like that developed through debate?

Interesting piece (particularly the comment stream) related to a theme in this blog — that students want a job, and how do we teach them about things they ought to know about even if they don’t recognize that they need it.

“You see, I didn’t want to waste my time having to learn about philosophy and political science. I just cared about writing code. Period. All that other stuff would have been worthless… in my humble opinion.”

via Are You a Blue Collar or White Collar Developer? — Datamation.com.

Each day, students in the School of One are given a unique lesson plan — a “daily playlist” — tailored to their learning style and rate of progress that includes a mix of virtual tutoring, in-class instruction and educational video games.

via The School of One – The 50 Best Inventions of 2009 – TIME.

If one wanted to do this for an introductory computer science course, what would we do?  What variables do we have available to tailor computing instruction to the individual student?  For example, do we know anything about learning styles for CS?

Here’s a particular version of that question that says something about the state of computing education: How do you help the student needing remediation?  If you have a student not doing well, what options do you have to help that student learn and catch up?

My sense is: Not many.  Most of our instructional repertoire in introductory computer science consists of material that students read (textbooks, PowerPoint slides), lecture sessions, and having students practice in front of an IDE.  What other options do we have?

• Tutoring sessions, particularly with peer-led team learning, could be added to support students who are falling behind.  Essentially, the variable here is “More teacher time.”
• Changing the pace, though the answer for remediation isn’t obvious.  Would you give the students more time per programming assignment?  Fewer assignments? Smaller programming assignments?  More but smaller?  Since we know that lower-performing students take more time per assignment, it’s not clear if it’s more help to give them more time, or make the assignments smaller (easier?), but maybe more of them to provide more practice.
• We could provide students with visualizations, but most of the results I’ve seen suggest that visualizations help the high-ability students to learn more, but they actually hurt low-ability students.
• We have a set of tools that we know are easier to get started with (e.g., Scratch, Alice, Etoys), but they may not be much help once a student has started with a more traditional course and language (Python, Java, C++) and now needs help.  I guess that, if a student was struggling with (say) IF statements in C++, you might use IF statements in Alice to help teach the concept. However, the overhead of learning Alice mid-course might be greater than the benefit, and might really frustrate the student (e.g., “I’m trying to understand C++! Why does learning Alice help me with that?!?”).
• There are some tools like JEROO and iList that look like the languages that students are study and have helped students.  We could use more tools like these.

In other disciplines, there are remediation options. For disciplines from English to Chemistry, there are Cliff notes, study guides, educational software, and instructional videos.  Some of these exist for CS, but there’s not much.  For most subjects, you can always fall back on re-learning the prerequisites. For example, if you’re having trouble with high school mathematics, there are lots of K-8 mathematics materials that one can fall back on.  We don’t have that bench strength that other disciplines enjoy.  CS instruction in high schools doesn’t look that different from CS instruction in colleges, in terms of materials and methods used.

I think that this is another example of how our educational practices in CS are aimed at the top half of the students.  The problem is that if you aim for the top half, you lose the bottom half.  However, if we aimed for the bottom half, everyone would learn, even if the top half were not as challenged.  Yes, we’d prefer to challenge everyone.  But thinking about a CS School of One has me thinking about how we would change how we teach to address the bottom half of students.

Yesterday I was in DC for a meeting of NSF Broadening Participation in Computing Alliance investigators.  It was a really useful and challenging meeting, where we had to go around the room and critique each others’ last proposals (!).  The goal was to improve how we’re thinking about our efforts and how we’re expressing them.  I’ll have more to say about the meeting in a moment, but first, I wanted to highlight a meme that was going around the room yesterday.

We computer science faculty have a bad rep!  Over and over yesterday, in one-on-one meetings and in group discussions, the notion that computer science faculty are a particularly grumpy and curmudgeonly group kept coming up.  Some examples:

• “Our <different kind of computing> faculty are willing to try all kinds of things to attract students and do outreach, but our Computer Science faculty insist that they will only do Scheme!  They’re just a bunch of curmudgeons!”
• A specialist in working with disabled students said that her colleagues ask her why she decided to work with computing students.  “Why did I decide to work with the most difficult and grumpy faculty on all of campus?”
• Another PI describing her efforts to inculcate change in her computer science department, “But we can’t even get the faculty to learn about new things! They’re happy with UNIX and want everyone to just do that!”

So my experience is that there is a significant percentage of more senior faculty of all disciplines are fairly set in their ways and are rather “grumpy” about change.  Maybe I fall in that category now, so I’m blinded to the claim I heard yesterday — that computer science senior faculty are particularly resistant to change and grumpy about it.

Before Barb Owens or others call me on it — of course, there are senior CS women faculty, too.  But it is the case that CS faculty of decades past have been male, so the characterization of “grumpy old men” is not inaccurate.  And it might be that the male faculty are even grumpier than the female faculty.

I can imagine how the claim that CS faculty are particularly grumpy could be true.  Computer science is a young discipline.  Senior faculty today spent their whole careers defining and defending their turf — “This is computer science, and that isn’t.”  At the same time, computer science has had dramatic change: From computer time being more expensive than human time, to the reverse; from memory being dear, to memory being plentiful; from sequential processing being the assumption, to today’s world where parallel processors are all that we can see going forward.  How often does a discipline change so many of its base assumptions in the lifetime of a faculty member?  Change is hard for anyone, and particularly so when you’ve spent your career making arguments that are weakened or changed by time.

Now, I don’t know that it’s true that CS faculty are particularly “grumpy.” Maybe it is.  The real point of the BPC discussions was that our resistance to change is counter-productive.  We need students who don’t look like us.  There are too few students who look and act like us to provide the computing labor and insights that our society needs.  We have to break out of our assumptions and the methods that have served us well up until now.  That’s hard, but we have to get past the “grumpiness.”

I think the fundamental thing that set Rails apart was a culture of putting the programmer first. The idea that Web programming should be fun and that programmers should be enjoying themselves.

The culture bred ideas like Convention over Configuration, where we standardized all the things that programmers do most of the time for most applications anyway.

via Open source identity: Ruby on Rails creator David Heinemeier Hansson – frameworks, open source, open source identity, ruby – CIO.

What makes programmers happy?  The Ruby on Rails creator says that it is, in part, creating standards (“Conventions”) that do things for the students.  Another school of thought is that programmers want flexibility.  These seem to be contrasting perspectives to me.  I suppose that the middle ground is that programmers want things that they don’t want to do already done for them, and they want flexibility with the things that they want to do.  My bet is that those things (what programmers want to deal with, and what they don’t want to deal with) vary from domain-to-domain, maybe even programmer-to-programmer.  Hard to design for.

What do we want for students?  Do we want lots of things done for them, or provide them with small pieces (like Lego blocks) that they can put together in a wide variety of different patterns?  Do they want standards or do they want flexibility?  What do we as teachers want for them?  Should we have structures that are in place, so that students can’t build anything but what they do build is supported (I’m thinking Alice and Scratch here, as examples)?  Or should we give them maximal flexibility so that they can assemble things and come to understand from the bottom-up (I’m thinking Pascal and the hardware-first approach of Patt and Patel)?

Bigger question: Should the answers to these things be different?  Is the balance of standards and flexibility that works for programmers what we also want for students?  I’m not suggesting the exact same tools are right for both novices and for experienced programmers, but I am wondering if the balance between what’s provided and what’s flexible might be similar.

Marlene Scardamalia and Carl Bereiter of the University of Toronto’s Ontario Institute for Studies in Education (OISE) have been arguing for years for “higher levels of agency” for children.  Think about what you do when you have a question: You go find a source (a website, a book, or an expert) and ask your questions to learn the answer.  Think about what we do with children in most classrooms: You find children who don’t know the questions or answers, put them in front of teachers who know both the questions and the answers, then the teacher asks the children questions.  Scardamalia and Bereiter want to find ways to put children in the former situation.

What would Scardamalia and Bereiter want to see for computing education?  I suggest that the analogy is that we think about students as wanting to build something, and we’re about giving them the tools to build that something with as much support and as little irrelevant detail as possible. But how do we get students to learn what’s useful and important for them, that they might not realize they need or that might not arise when they build yet-another-video-game?  That’s the real challenge of placing more agency in the hands of the students — how do you get them to use that agency wisely?

I’ve been thinking a lot about two of the papers at Informatics Education Europe last week.

First paper: Faculty at UPC Barcelona decided that students were coming into CS2 with insufficient problem-solving skill.  The decided that part of the problem is that paper-based tests lead to grading based on student intent instead of on the actual code, e.g., we let students get away with more errors.  They decided to move to a pure “problem-oriented approach” for their CS1.  Students are given 100 worked example problems, and 200 problems to solve.  Students submit their solutions on-line, and get feedback on how well their programs succeeded against a test suite.  First test is free, all others dock points if unsuccessful.

The project was successful in that students coming into CS2 have much better problem-solving skills.  Unfortunately, only 20-25% of the students make it through.

That result surprised me, given what we know about worked examples research.  How much do students make use of the worked examples?  Answer: Almost none at all.  Students just try to solve the problems, and don’t actually try to learn anything.

Second paper: The Open University in The Netherlands actually teaches their CS1 face-to-face, for the most part.  Teacher and students drive to some common location and conduct classes in small groups of about 30. They decided to try an experiment where they ran the classes completely on-line.  One section of 13 was asynchronous — students posted to a threaded discussion group. Another section of 15 met in a synchronous forum with text chat and a shared whiteboard.  At the end of the 12 week term, the asynchronous class went from 13 down to 1, while the synchronous class went from 15 to 10, which was the drop-out rate that they normally have with face-to-face classes.

While these are both really interesting papers, nobody would ever want to do these classes as described again.  They make for interesting papers, where they only try one pure approach: Just problems, just synchronous, just asynchronous.  A real, successful class would be a hybrid of different approaches.

• Got an expensive face-to-face class? Add some synchronous on-line activities in lieu of some lectures.
• Got an asynchronous class where students are dropping out?  Add some synchronous and even face-to-face sessions to build up motivation.
• If students don’t read the problems, add some assignments where students have to demonstrate that they read, not just coded.  Add some lectures where problems are discussed.

Why don’t we read more papers like that?  Because hybrids don’t play well with our sense of rigorous experimental research.  We want to know exactly what inputs influenced what outcomes.  We want to know that problems or asynchronous discussions failed or succeeded, period.  Making it work doesn’t make for a paper that gets accepted in many forums.

The learning sciences community faced this same problem.  You can do a study that answers a question and results in a publication, but doesn’t really result in successful classroom.  Or you can mix things up so that it really works, but then you can’t get the results published.  They defined a model of research called design-based research (DBR), first proposed by Alan Collins and Ann Brown.  The idea is to build a classroom that works.  Through a process of measuring and iterating, or drawing off particular hypotheses to test in laboratory experiments, you develop evidence for what factors are influencing what outcomes.  DBR recognizes, however, that good solutions tend to have multiple interacting factors.

We need hybrid approaches.  Pure approaches only lead to good papers.  We have too many challenges in computing education to aim for only good papers.  We need great papers that show working educational contexts that other can replicate, where the factors are messy and will take us a while to tease apart and understand completely.  Documenting how we get it right and finding someplace to publish those papers are the first step. Understanding it factor-by-factor is a later step.

Just found a great piece of email in my (massive!) unread pile from the Board of Regents of the University System of Georgia.

Here’s the latest on the AP CS. After much thought and discussions on the AP CS course, we have decided to accept the AP CS course as a 4^th course for admission to the USG institutions. However, the course will be listed in a separate category.

To follow up…..I do have a question for you. Would it be helpful to the students and our institutions if the AP CS course was to be accepted as a fourth science course only, or as a fourth science OR math course? We would like to do what’s best for the students and our institutions.

This could hardly be a better answer for us.  Computing is something different, so it gets a new category.  Of course, yes, we have asked for the “science OR math” option — which also matches with the understanding that computing has aspects of both, and helps students with either.

There’s another step yet.  This is the University saying, “This will count for University admissions.”  Next, the Georgia Department of Education has to say, “And we’ll count that for high school graduation.”  Normally, that should be nearly automatic, but creating a whole new category of courses may take some more convincing.  We’ll keep you informed.

When Barb was a little girl, her grandfather was mayor for 10 years of Ubly, a small town (no traffic light, just one blinking light in the center of town) in the “Thumb” of Michigan.  The town had a movie theater, a grocery, and a thriving social community.  Today, Ubly is much quieter.  The movie theater and grocery have both gone.  Most of the farmers have gone from Ubly.

Yesterday, Barb and I visited Soppe-le-Haut and Soppe-le-Bas in France, the towns where that grandfather’s ancestors came from.  Both town are small but thriving, with a few dozen homes each.  Each home has a barn. Most of those barns contain tractors.  Almost all of the homes have chickens, cows, or horses in their yards.

I don’t really understand the economics of that difference.  Why did American small farms fall to large corporate farms, while Europe retained their small farms?  Why did Barb’s grandfather’s town shrink while his ancestors town thrived?

A new book by Patrick J. Carr and Maria J. Kefalas is also concerned about the declining rural America.  Their new book Hollowing Out the Middle and the interview with them in this week’s Newsweek describes their suggested solution.  In part, they would like to see rural communities draw back young families, with a strong Internet infrastructure, to support telecommuting.  Information technology is one of their targeted industries.

Why doesn’t that just happen?  In keeping with a recent theme of this blog, these authors point out that the rural education system is aimed at supporting the “best and brightest,” and ignoring the bottom half of the students — who are most likely to stay.

First, by changing their attitudes toward their high-school graduates. Small towns traditionally put all their efforts behind the smart students (whom the authors label “Achievers”), pushing them out to four-year universities in cities, where they are much more likely to succeed and, unfortunately for the town, much more likely to stay. Students who are less accomplished or driven are given little support, but they are also the ones who are most likely to remain in their small towns post-graduation. In order to make sure these kids succeed, and thus benefit the community, the authors argue, they need to be better trained in areas such as computer technology, health care, sustainable agriculture, and green energy, areas geared toward the modern global economy.

I suggest that we do not currently know how to make these authors’ vision come to fruition.  Our CS1 methods lose the bottom 30-50% of the students.  Those are the students that these authors would like to see become the backbone of the rural economy in the United States, telecommuting to become part of distributed software development teams.  We need to develop teaching methods that lead to success for a greater number of students, to educate the “rest” of the students, for visions like this to succeed.

My daughter turned 12 on Tuesday, and unfortunately, she was ill.  Dad hung out with her, and played whatever video games she wanted.  One of those she picked was Guitar Hero, so I finally got time to play it repeatedly.  Y’know — it was kind of fun!

Back in December, when I first got Guitar Hero, I wrote a blog post where I agreed with Alan that Guitar Hero is not nearly as good as learning a real musical instrument.  At that time, I wrote:

Guitar Hero might still be fun.  But it’s just fun.  I might learn to do well with it.  But it would be learning that I don’t particularly value, that makes me better.

Now I’m thinking that I might want to eat those words.  I found Guitar Hero hard.  I own a guitar and have taken guitar lessons for two semesters.  (Even putting it in terms of “semesters” suggests how long ago it was.)  Some of my challenges in learning to play a guitar included doing two different things with my hands, and switching chords and strumming to keep the rhythm.  I noticed that that’s exactly what I was having a hard time doing with Guitar Hero.  I also noticed the guitar parts of rock songs — songs that I had heard a million times before but never had noticed all the guitar parts previously. I noticed because I missed my cues, and so those guitar parts were missing.  While I have known Foghat and Pat Benatar for literally decades, Guitar Hero had me listening in a different way.

It occurred to me that Guitar Hero could be a form of scaffolding, a reduction in cognitive load that allows one to focus on one set of skills before dealing with all the skills at once.  Cognitive scaffolding is much like the physical scaffolding, “a temporary support system used until the task is complete and the building stands without support.”  Now, Guitar Hero would only be successful as a form of scaffolding if it actually leads to the full task, that it doesn’t supplant it.  In education terms, if Guitar Hero could fade and if it doesn’t lead to negative transfer, e.g., “I’m great at Guitar Hero, but a real guitar is completely different.”

I did some hunting for studies that have explored the use of Guitar Hero to scaffold real music education.  I could not find any educational psychology or music education studies that have explored Guitar Hero as a form of scaffolding or as a tutor to reduce cognitive load.  I did find papers in music technology that hold up Guitar Hero as a model for future educational music technology! My favorite of these is a paper by Percival, Wang, and Tzanetakis that provides an overview of how multimedia technolgoies are being used to assist in music education.  They point out additional lessons that students are learning with tools like Guitar Hero that I hadn’t noticed.  For example, the physical effort of playing an instrument is more significant than non-players realize, and Guitar Hero (and similar tools) build up the right muscles in the right ways (or so they theorize — no direct studies of Guitar Hero are cited).  The paper also argues that getting students to do something daily has a huge impact on music learning and performance, even if it’s a tutorial activity.

Now here’s the critical question: Does Guitar Hero lead to real music playing, or is it a stopping point?  Nobody is arguing that playing Guitar Hero is making music, that I can see.  Does it work as scaffolding?

I don’t know, but I’m now wondering: Does it matter?  If Guitar Hero stops some people from becoming musicians, then it is a problem.  If some people, who might have pushed themselves to become musicians, decide that Guitar Hero is hard enough, then Guitar Hero is doing a disservice.  But if that’s not true, and people who never would become musicians, have a better appreciation for the music and a better understanding of the athleticism of musicians because of Guitar Hero, then Guitar Hero is providing a benefit.

These are computing education questions.  You have all heard faculty who insist on using Eclipse in their introductory classes, because that’s what real software engineers use.  We have recently read in comments on this blog that students should use “standard tools” and “learn science the way scientists understand it.”  We also know from educational psychology that engaging introductory students in the same activity as experts only works for the best students.  The bottom half of the students get frustrated and fail.

We need Guitar Hero for computer science.  We need more activities that are not what the experts do, that are fun and get students to practice more often, that are scaffolding, and that reduce cognitive load.  We have some, like Scratch and eToys.  We need more. Insisting on the experts’ tools for all students leads to the 30-50% failure rates that we’re seeing today.  We have to be doing more for the rest of the students.

You don’t have to be an engineer to program a computer. In fact, programming is like learning another language, which just happens to be easier the younger you are. In many ways, learning a programming language at a young age equips youth with skills that will be very marketable in the future, no matter what profession they decide on later.

via Teach a Kid to Program – Wired How-To Wiki.

There are some interesting suggestions on this page.  I hadn’t thought about Basic on a TI calculator as a syntax-light intro to computing.

Thomas Friedman has a really interesting NYTimes column about education and the cause of the Great Recession this week:

Now that we are picking up the pieces, we need to understand that it is not only our financial system that needs a reboot and an upgrade, but also our public school system. Otherwise, the jobless recovery won’t be just a passing phase, but our future.“Our education failure is the largest contributing factor to the decline of the American worker’s global competitiveness, particularly at the middle and bottom ranges,” argued Martin, a former global executive with PepsiCo and Kraft Europe and now an international investor.

This theme, that we’re particularly ignoring the bottom half (2/3’s?) of our population, occurs again later in the column:

“…the bottom half of the top, those engineers and programmers working on more routine tasks and not actively engaged in developing new ideas or recombining existing technologies or thinking about what new customers want, have done poorly. They’ve been much more exposed to global competitors that make them easily substitutable.”

I have been exploring this theme, that we’re ignoring all-but-the-best students, in my recent blog posts, about how we choose exciting the top students instead of educating all, and about how the movement to on-line education tends to wipe out the bottom half of the student body.  The top students don’t need the phonics of computing education, but those lessons that help students move farther and progress faster could do a lot for the bottom half.

Friedman is also saying that what we are teaching has to change, too.  That’s probably right.  But with 30-50% failure rates in CS1, we are currently not teaching much of anything about computer science to the students in the lower half.  Maybe we should start by helping them succeed in those first classes, so we can get to the entrepeneurship and global thinking that Friedman wants, too.

ACM (the Association for Computing Machinery) joins with several partners from the computing community to commend the U.S. House of Representatives’ passage of a resolution to raise the profile of computer science as a transforming industry that drives technology innovation and bolsters economic productivity.  The resolution, H. RES. 558, sponsored by Congressmen Vernon Ehlers (R-MI) and Jared Polis (D-CO), designates the week of December 7 as “National Computer Science Education Week.”

via Congress Endorses Computer Science Education as Driver of Innovation, Economic Growth — Association for Computing Machinery.

In her Blog@CACM posting, Introductory Computer Science Lessons–Take Heart!, Judy Robertson responds to my blog about how we don’t teach CS well according to educational psychology literature.  She argues that Kirchner, Seller, and Clark are not directly speaking to our CS practices and goals (which may be true).  She also suggests that the practices that KSC recommends are those we already practice in CS education, e.g., use of worksheets and multiple worked examples.  That may be true at Judy’s institution, but is certainly not the case in most US institutions that I visit.

Imagine that the United States’ Constitution and Bill of Rights were being re-written today.  I’ll bet that something would be said about personal rights of Information.  I’m no constitutional law expert, but it looks to my novice eyes as if several rights about information are already there.  We Americans already have a right to own property, and information can represent intellectual property.  We already have a right to privacy, which is used to protect our information from perusal.  We also have a right to bear arms.  While there is some debate as to whether that means individually or in the sense of state militia, I believe that most people believe that they have a right to protect themselves and their property.

Should we teach students how to utilize information technology as an offensive force?  I’m not suggesting teach them to be rogue hackers or information terrorists.  Some interpret the right to bear arms to mean that people should be invested with the power to overthrow their government, should the people see that as necessary.  Whether you subscribe to that belief or not, it’s clear that uprisings around the world have been enabled by information technology, from fax machines in China to Twitter and Facebook in Iran.  I watched “Valkyrie” this weekend, and visited the Holocaust Museum in DC this last summer, and both experiences impressed and shocked me with how well Nazi Germany used information technology to support and further their agenda.  Information is a property, and information technology is a form of arms.  Students should be aware of how information technology can be used as an offensive force in order to learn how to defend against it.

Most of the new courses being devised to teach “Computational Thinking” aim toward defining the big ideas of computation, the powerful “automation of abstractions” that enables our society.  I’ve been thinking lately about what we should be teaching students in terms of being able to protect themselves and how information technology can be used as arms. What should we teach?

Here are a few items on my list:

• All information that we put in a computer is represented as bits.  A “bit” can be represented as a voltage in a wire, or a value in the red channel of a pixel, or as a statistical abnormality in a pattern.  Meaningful data (including code, as for a virus or worm) can be hidden in lots of ways.
• Information can be automated.  Programs can generate spam messages that look tailored to the individual and sent to millions.
• Information takes time to process.  Thus, too many hits on a server can result in Denial of Service.
• Information can be correlated.  All students should see how a database “join” works, so that they understand how information about them can be connected to other data elsewhere to develop shockingly complete pictures of themselves (possibly enough to enable identity theft).
• All digitized representations are representations, most likely lacking in some detail or some data.  For example, CD’s can’t capture all sound (like high-pitched sounds that only a dog can hear), and digital pictures have limits to their resolution and color fidelity.  Similarly, there are holes in any digital information source, which might be exploited.
• The Internet is open.  You should presume that all of your sent email, including attachments, is readable by anyone anywhere, as if the reader was sitting at your computer.  To protect the information you send on the network, it should be encrypted, so that a potential reader couldn’t read it (without the right codes) even if seated at your computer.
• Internet protocols are just agreements.  They are not fixed in stone, nor defined by physical or mathematical laws.  They are mostly simple, so it’s possible to write clients and servers for them.  If necessary, new ones can be recreated.

Most of these are probably items on most “big ideas” lists. I’m just suggesting a different perspective to come up with them.  Now, I don’t believe the Constitution and Bill of Rights are being re-written today. That’s just a thought experiment.  I do wonder if we should be teaching about information technology (both as property and arms) to support our students in protecting their existing rights.  It’s a different purpose for “Computational Thinking” — in a defensive and offensive perspective.

My colleague, Beki Grinter, just posted an intriguing blog entry titled Reflections on ICT4D which tells us a lot about the priorities in computer science.  “ICT4D” is Information and Communications Technologies for (4) the Developing world.  Beki’s blog talks about the growth of this interdisciplinary field including classes and degree programs (such as the “Computer4Good” classes at Georgia Tech that I’ve already whined about).

What Beki does in her post is use the emergence of ICT4D to make observations about the assumptions and the priorities of our field.  Some of the ones that particularly struck me:

• Few people who do computer science living in the conditions of the developing world.  Thus, we can’t be expected to understand their problems (or rather, some of us may expect that we can, but we honestly can’t).  Problem exploration and definition is thus an important part of ICT4D, as it is for HCI — but that may be part of what keeps HCI researchers from being seen as rigorous as others in academia.  Admitting that there are alternative perspectives, views, and experiences of the world, and developing methods for understanding those, should be a contribution, not a detriment.
• The solutions that we develop in computer science rely on an infrastructure that is invisible to our discipline: a power infrastructure, an educational infrastructure that ensures (for one) that our users can (mostly) read, and a retail infrastructure for distributing our products.  ICT4D is an academic discipline that starts by removing those assumptions.

The most interesting insight that I got from Beki’s article is how we focus on the solutions to the problems in computer science, where ICT4D is about the problems.  As a computing educator, I hear repeatedly from teachers, “Computer science is problem-solving on computers!”  Yet, as Beki points out, we organize our discipline and our findings on characteristics of the solution, not the problem.

• Why are the programming language, HCI, and computing education people in different conferences and journals, if they’re all about the same problem of human-computer understanding and communication?
• The “biggest question in computer science” (as Jeanette Wing called it), “Does P=NP?” is in some sense a question “We have these solutions to these problems that are ‘NP,’ and we’re wondering if there is a ‘P’ solution to those problems.”  We haven’t classified the problem, we’ve classified the solution, and we’re wondering if our solutions are in some way general descriptions or characteristics of the problem.
• The recent discussion on my last blog post talks about how we in computer science tend to dismiss (as mathematics does, says one commentor) our tools and an understanding of how the tools influence our process.  That’s how we reach solutions, and we tend not to care about that.  We tend to care about the solutions not the process or tools we used to reach them, and that’s a shame.  Our solutions have dramatic impacts on society, and it is important to understand how we got there.

Beki avoids critiquing computer science (unlike me, I’m afraid).  Instead, she uses the developing study of ICT4D as a lens or mirror to provide us insights onto what we do, what we assume, and what we prioritize.  I encourage you to take a peek and see what you see in Beki’s mirror.

I (finally) finished grading midterms and first round of grad student essays from my joint undergrad/grad “Educational Technology” class last night. The first phase of the class was an exploration of the proposition: “Computing creates an opportunity to program, and learning to program creates an opportunity to learn other things better.”

Many of my grad students referenced a wonderful essay by Michael Mateas, analyzing the Alan Perlis 1961 talk where he called for everyone at the university to learn to program: Procedural Literacy: Educating the New Media Practitioner.  An often quoted section from Michael’s essay focused on an interaction between Alan Perlis and Peter Elias, where Elias saw programming as a mere technician’s job:

“I have a feeling that if over the next ten years we train a third of our undergraduates at M.I.T. in programming, this will generate enough worthwhile languages for us to be able to stop, and that succeeding undergraduates will face the console with such a natural keyboard and such a natural language that there will be very little left, if anything, to the teaching of programming…”

Michael disagrees with Elias’ view:

The problem with this vision is that programming is really about describing processes, describing complex flows of cause and effect, and given that it takes work to describe processes, programming will always involve work, never achieving this frictionless ideal. Any tools that reduce the friction for a certain class of programs, will dramatically increase the friction for other classes of programs.

Can the programming language simply “disappear” from the task of programming?  I think Elias’ view represents that of most computer scientists, that the language is a mere detail in education or in actual programming. It’s omething to get rid of or ignore. Or is Michael right, and there will always be some “friction” involved?  If there is friction, how do we teach it?  Michael wants us to teach the friction, wants us to teach the “worldview” that each language builds upon.  His view is like Ian Bogost’s “Platform Studies” which suggests that understanding this “friction” is important to understanding how the technology has developed and impacts us.

Michael goes on to describe what a curriculum focused on computer-as-medium might look like:

It is important not to view computation for new media students as a dumbed-down version of the traditional computer science courses. Teaching programming for artists and humanists shouldn’t merely be simplified computer science with lots of visually engaging examples, but rather an alternative CS curriculum.

I think Michael is right. It’s probably not surprising that Michael was on the committee that created our Computational Medium degree here at Georgia Tech.  What I worry about in Michael’s comment is the implication for the Computer Science curriculum program.  What does that say about computer science if our goal is to ignore the “friction,” when that “friction” is actually important, interesting, and is part of what is most challenging for our students to learn?  What does it say about computer science if wanting to teach programming for creative expression demands the creation of another curriculum?

Ray Lister, who’s been really good at provoking my thinking lately, made an interesting response to Ed Gehringer on the SIGCSE members list last night:

On Sat, 3 Oct 2009, Ed Gehringer wrote:
> In the last few years, I’ve been concerned that my tests and exams
> have been given in an environment that is increasingly artificial.
> No one would think of writing code while away from a computer …

Really?

For today’s novice, who is learning to program in an era where
sitting in front of the computer means that the next compile-and-run is
only a mouse click away, it is tantalizingly easy but ultimately futile
to pursue a strategy of trying to get the computer to do the thinking
for them.

I think we need to place greater explicit pedagogical emphasis on
performing programming activities *away* from the computer. I’m
not advocating zero use of machine-based testing. But I think
testing students on paper is part of a healthy grading mix.

(Apologies in advance if I’ve just started an email storm.)

Raymond

Dr. Raymond Lister
Science Teaching and Learning Fellow,
University of British Columbia,
Department of Computer Science,
Vancouver, Canada

Ray’s call for paper-based and computer-based assessment is interesting.  My recent reading spree on cognitive load has me thinking about student learning activities that are on the computer, but not in the IDE.  For example, how about tools that let a student enter an equation or a loop in response to a question, and then a parser (or maybe even just a tokenizer for some expressions) gives the student feedback that is tuned to that problem?  Not just “You’re missing a right paren” but “You’re missing the term where you divide by the count to get the average” or even “Hmm, doing it like that will miss the last item in the list.”  These could be used for testing, as Ed’s question originally suggested, but also new kinds of student activities for learning.

Intro to CS courses will be about programming, enforced by student and teacher culture.  However, programming is a pretty blunt instrument for helping students learn — there are lots of cognitively complex activities there, with little useful feedback.  The educational psychology literature I’ve been reading has me realizing what few tools we computing educators have right now to facilitate student learning about computing.  What if our students can’t solve the big programming assignments we assign?  Well, we can give them a smaller programming assignment, or a different language for programming. Katrin Becker came up with a nice list in her blog of educational activities that aren’t just “generate program (in whatever language).”

The non-programming activities on Katrin’s list, though, are mostly without computational support.  Could we use our own technology to support learning about the technology?  How about tools that help a student in identifying the differences between two programs by highlighting comparable parts? Or can parse a student’s natural language explanation of a program to provide feedback?  Or ask a student to generate the output of a program, and then use pattern matching to give feedback on that response?  We might use all this cool computing technology we have to provide learning experiences and feedback to students other than just programming error messages from the IDE.  Surely, we can figure out more to do with a computer to help learning than just to build more languages and IDEs.

I’ve been interested in John Sweller and Cognitive Load Theory since reading Ray Lister’s ACE keynote paper from a couple year’s back.  I’ve wanted to learn more, and as all professors will tell you, the best way to learn something (or at least, to find time to learn it) is to teach it. So, I assigned several papers on the topic (first three papers in the References) to my educational technology class.  Those three papers set me on a paper finding-and-reading spree which is having a dramatic effect on how I think about we teach about computing.

Let me start out with a strawman position of how we teach introductory computing.  I know it won’t be how you and your institution teach computing, but I hope that it’s got some elements of how most American schools teach CS1:

We lecture students on how to use a particular element of computing, say variables, assignments, and function calls.  We walk through 2-3 examples of using those elements, and assign reading from a textbook that might present 1-2 of those examples with maybe a couple others.  We then assign a programming assignment that the students have never seen before whose solution will require use of those programming elements, often with authentic tools or IDEs like those used by experts.

The original 1985 Sweller and Cooper paper had five studies with similar set-ups.  There are two groups of students, each of which is shown two worked-out algebra problems.  Our experimental group then gets eight more algebra problems, completely worked out. Our control group solves those eight more problems.  As you might imagine, the control group takes five times as long to complete the eight problems than the experiment group takes to simply read them.  Both groups then get new problems to solve. The experimental group solves the problems in half the time and with fewer errors than the control group. Not problem-solving leads to better problem-solving skills than those doing problem-solving. That’s when Educational Psychologists began to question “learning by doing” and the idea that we should best teach problem-solving by having students solve problems.

The paper by Kirschner, Sweller, and Clark is the most outspoken and most interesting of the papers in this thread of research. Their title states their basic premise: “Why Minimal Guidance During Instruction Does Not Work: An Analysis of the Failure of Constructivist, Discovery, Problem-Based, Experiential, and Inquiry-Based Teaching.”  They describe the problem like this:

On one side of this argument are those advocating the hypothesis that people learn best in an unguided or
minimally guided environment, generally defined as one in which learners, rather than being presented with essential information, must discover or construct essential information for themselves (e.g., Bruner, 1961; Papert, 1980; Steffe & Gale, 1995). On the other side are those suggesting that novice learners should be provided with direct instructional guidance on the concepts and procedures required by a particular discipline and should not be left to discover those procedures by themselves (e.g., Cronbach & Snow, 1977; Klahr & Nigam, 2004; Mayer, 2004; Shulman & Keisler, 1966; Sweller, 2003).

What exactly is minimal instruction?  And are they really describing us? I think this quote describes how we work in computing education (as modeled above) pretty well:

There seem to be two main assumptions underlying instructional programs using minimal guidance. First they challenge students to solve “authentic” problems or acquire complex knowledge in information-rich settings based on the assumption that having learners construct their own solutions leads to the most effective learning experience. Second, they appear to assume that knowledge can best be acquired through experience based on the procedures of the discipline (i.e., seeing the pedagogic content of the learning experience as identical to the methods and processes or epistemology of the discipline being studied; Kirschner, 1992).

That is, “people should learn to program by constructing program from the basic information on the language, and they should do it in the same way that experts do it.”  The paper then goes on to present all the evidence showing that this “minimally-guided instruction” does not work.

After a half-century of advocacy associated with instruction using minimal guidance, it appears that there is no body of research supporting the technique. In so far as there is any evidence from controlled studies, it almost uniformly supports direct, strong instructional guidance rather than constructivist-based minimal guidance during the instruction of novice to intermediate learners.

Now, in the same issue of Educational Psychologist there were rebuttals to KSC, and there have been more written since then, including one by my colleague Cindy Hmelo-Silver.  What’s striking about these rebuttals is that they basically say, “But not problem-based and inquiry-based learning! Those are actually guided, scaffolded forms of instruction.”  What’s striking is that no one challenges KSC on the basic premise, that putting introductory students in the position of discovering information for themselves is a bad idea! In general, the Educational Psychology community (from the papers I’ve read) says that the model I describe above is an ineffective way to teach introductory students.

So what’s wrong with my strawman?  First, way too few examples.  The original Sweller and Cooper paper used ten examples of just a simple algebraic manipulation.  In the studies where worked examples have been used with computer programming (yes, it has been used with computer programming, and yes, it works there, too) by Pete Pirolli and Mimi Recker, the examples were in the 6-12 range for something like recursion.  2-5 examples are too few.

Second, we should not be asking students to solve something new.  They should practice the same information, demonstrate that they got that.  What KSC shows is that that approach takes too much time and leads to too little learning — it overloads the cognitive ability of the learner.  Only the very best students can succeed in when simply thrown in front of a speeding interpreter or compiler.  (I think that explains the “two humps” pretty darn well — it’s not the discipline, but how we teach it that results in the bimodal distribution.)

What should we do instead?  That’s a big open question.  Lots of options have been explored in this literature, from using tools like intelligent tutors to focusing on program “completion” problems (van Merrie¨nboer and Krammer in 1987 got great results using completion rather than program generation). I think that a lot of TeachScheme with DrScheme language levels has many of the right characteristics.  Media Computation provides the right number of examples with minimal changes during practice, but still deals with the speeding interpreter problem. The bottomline is that asking students to program doesn’t lead to them learning programming — as Richard Mayer (famous educational psychologist put it) says it promotes behavioral activity too early in the learning process, when learners should be cognitively active. (How often have you seen students programming without thinking much?)  We need to figure out what’s the right kind of practice for CS, and how much, and how to motivate students to take seriously examples and practice, as opposed to full programming.

This literature is not saying never program.  Rather, it’s a bad way to start. Students need the opportunity to gain knowledge first before programming, just as with reading.  Later, there is a expertise reversal effect, where the worked example effect disappears then reverses.  Students do learn better with real programming, real problem-solving.  There is a place for minimally guided student activity, including programming.  It’s just not at the beginning.

Finally, it turns out that textbooks are not the best medium for teaching programming.  The Atkinson, Derry et al. article does a wonderful job of surveying what we know about teaching with examples.  One of the findings is the Modality Effect.  Using text to explain something that is visual (like a program) leads to more extraneous cognitive processing than using audio for the explanation.  Given that we work with computers capable of multimedia, we should be able to do much better than textbooks.

Overall, I find this literature unintuitive.  It seems obvious to me that the way to learn to program is by programming.  It seems obvious to me that real programming can be motivating.  But KSC respond to this, too.

Why do outstanding scientists who demand rigorous proof for scientific assertions in their research continue to use and, indeed defend on the bias of intuition alone, teaching methods that are not the most effective?

This literature doesn’t offer a lot of obvious answers for how to do computing education better.  It does, however, provide strong evidence that what we’re doing wrong, and offers pointers to how other disciplines have done it better.  It’s a challenge to us to question our practice. It’s up to us to use these lessons and models to improve our teaching practice.

References

• Atkinson, R. K., Derry, S. J., Renkl, A., & Wortham, D. W. (2000). Learning from examples: Instructional principles from the worked examples research. Review of Educational Research, 70, 181–214.
• Kirschner, P. A., Sweller, J., and Clark, R. E. (2006) Why minimal guidance during instruction does not work: an analysis of the failure of constructivist, discovery, problem-based, experiential, and inquiry-based teaching. Educational Psychologist 41 (2) 75-86
• Sweller, J., & Cooper, G. A. (1985). “The use of worked examples as a substitute for problem solving in learning algebra”. Cognition and Instruction 2 (1): 59–89. doi:10.1207/s1532690xci0201_3.
• Scaffolding and Achievement in Problem-Based and Inquiry Learning: A Response to Kirschner, Sweller, and Clark (2006) Hmelo-Silver, Duncan, & Chinn. (2007). Educational Psychologist, 42(2), 99–107

I’m at the ACM Education Council meeting in Vancouver this weekend.  One of the topics of conversation is whether the ACM should push to make computer science a required subject in US high schools.  The argument is that computing education will only be taken seriously (e.g., receive funding, get teacher certifications and standard curricula, get treated well by No Child Left Behind) if it was a required subject, like other sciences and mathematics.

I finally did read Lockhart’s Lament that Ian Bogost talked about in his recent blog post.  Lockhart’s essay starts out with a painter and a musician having horrible nightmare’s about their subjects becoming “required” and how that meant draining all life out of the subject until it was an easily taught and easily measured husk of a subject.  Lockhart’s point is that this is exactly what has happened with mathematics.  I found his essay interesting, but ultimately, defeatist and even narcissistic. Lockhart complains about how badly his beloved mathematics is treated. Yet he offers no way out, no solutions for balancing the demands of compulsory education at a national scale and the desire to keep the art and soul of mathematics. His despise for teachers and education schools makes it unlikely that his arguments will have any sway with them in making things better.

Still, I think he raises excellent points to consider for computing education.  I work  on the Commission to design the new AP exam in Computer Science, and it’s hard to define the test scope and range exactly enough to make a standardized test, and yet still encourages students to explore and be creative with computing.  If computer science were made a mandatory subject, it would have to be dissected and classified and standardized even further.  Would a computer science requirement be the death of the “Beauty, Joy, and Awe” (in terms of the popular SIGCSE presentations) of computer science?  Is it a necessary process that defining a subject in NCLB terms means reducing it to a husk of its former self?  How can we teach teachers to meet the standards and still ensure that what’s interesting about computing remains — even if we can’t come up with an observable standard that would demonstrate that “students find computing creative and fun”?

In 2005, Merrick Furst (then, our associate dean for undergraduate education) said to me, “I think of your Media Computation and contextualized computing as a kind of ‘whole language‘ approach to computing education.  What are the phonics?  What’s the computer science equivalent of the scales and etudes that musicians practice with to get the basics down?”  At the time, I replied that getting students to understand why they’re learning to program, the relevance of what we were teaching them, was the most important factor. I still think that. But I’ve been pondering the phonics question for the last four years.

I was reminded of that question when listening to the NPR report on the end of PBS’ ‘Reading Rainbow.’ The beginning of the report chalked the demise up to a lack of funds, but as it went on, the report really sounded like a change of heart at PBS–driven by research findings.

“Reading Rainbow taught kids why to read,” [John] Grant [of WNED Buffalo] says. “You know, the love of reading — [the show] encouraged kids to pick up a book and to read.”

Linda Simensky, vice president for children’s programming at PBS, says that when Reading Rainbow was developed in the early 1980s, it was an era when the question was: “How do we get kids to read books?”

Since then, she explains, research has shown that teaching the mechanics of reading should be the network’s priority.

“Teaching the mechanics” — that’s what the “phonics” of computing education is about.  Context tells us why.  The mechanics tell us how.

We do a lousy job of teaching the mechanics of programming in computing classes. Our traditional tools of teaching programming are lecture and student practice with the interpreter or compiler.

• Pair-programming is just a twist on the student practice that doesn’t make the mechanics easier.
• Think about the perennial problem in Java of learning where to put the semi-colons.  How do we help with that?  We lecture on where to put semi-colons — yeah, we know how effective that is.  We show example code — better than just lecturing, but since our assignments are rarely modification of code, students are mostly dealing with semi-colons on a blank sheet.  Then, we throw students to the Java compiler, whose error messages in response to a missing or misplaced semi-colon are awful.
• Visual languages like Scratch or Alice reduce the mechanics.  For CS students, they just postpone the inevitable. I don’t know of any evidence that the mechanics are easier in the textual language after facing the visual languages.

If the research on reading applies to computer science, then we ought to be doing much more to convey to students the mechanics of programming.  What kinds of mechanics are important to teach?  I’ve thought of three, and I’d really appreciate hearing your suggestions on others:

• The syntax of the programming language. I understand (somewhat) while error messages in the full compiler can’t be made much better.  But surely we can build tools/tutorials/drills/etudes where students could practice the nitty-gritty details of language syntax with better feedback than compiler error messages.  I feel guilty every time my Python students get the indentation wrong in their programs, because the error message is about quotation or indentation errors “somewhere around line X.” Surely I could build something to help them learn indentation short of tossing them in front of a speeding interpreter?
• How to read code.  Everyone who comes to lecture gets to see and hear how the lecturer reads code.  All 30% of them.  There is a skill to knowing what to attend to in a program.  Everyone knows to simply skip “public static void” in the main method of a Java class — everyone except the novice who doesn’t know which words are important and which can be safely ignored.
• How to tinker with code.  Given a piece of code that you’re trying to understand, you know where to put print statements and what constants are worth tweaking to see the impact.  How does a novice know that?  We know that changing “i” to “j” as the index to the loop isn’t all that useful. How did we learn that? How do we teach that?

These activities are in the class of things that we experts never think about.  They’re the “obvious” things that we simply ignore.  Exactly! That’s what the “phonics”/mechanics are.  How do we teach them?  As experts, we know to simply ignore those matters and do them without thinking.  As novices, they are yet another distraction, and cognitive load theory suggests that those “distractions” add up.  In the end, we only have 7+/-2 chunks — that’s a human limit, and all those distractions are chunks that quickly add up to an impediment to getting at the learning we care about.

These “phonics”/mechanics are important, not just for the novice, but for the expert who is trying to bring herself up to speed on the latest technology.  The practicing programmer who wants to learn Ruby or Scala doesn’t need to know why to program in these languages — she already has that.  She wants to know how.  She wants the mechanics of the language.  Research on how to teach “phonics”/mechanics of a new language would go a long way towards bringing her up to speed on the new technology.  (I’m choosing “she” in these examples explicitly because I’ve been thinking for a year now about the implications of Caroline Simard’s report for the Anita Borg Institute on the needs of mid-level technical women in IT.)

Teaching the “phonics”/mechanics of computing education is on my mind a lot these days.  I’m thinking that it may be our most significant point of leverage in improving computing education.  New curricula may not get adopted.  The phonics of computing education crosses all curricula. Getting the phonics right helps both the novice and the practicing programmer learn new skills.  Done right, phonics can be taught self-paced, even via distance learning, to act as a supplement to existing instruction.  I still think that the context is our most important change to improve computing education, but teaching the phonics/mechanics well may be the most universal improvement we can make, the one that can help everyone regardless of curriculum.

One of the features of CS1 outcomes that has had teachers perplexed for years is the “Two Humps” phenomenon: Some students really get it, and some don’t.  Grade curves for CS1’s typically have two humps, one for each group of students.  What causes that?  The mythical “Geek Gene” is one explanation.

Anthony Robins has an alternative explanation.  He thinks that it’s because everything we do in intro programming builds on the earlier stuff.  If you ever get behind, you’re toast — you can’t do the later homework without getting the earlier homework right.

Michael Kölling has built on Anthony’s explanation to develop a new way of teaching his CS1, which he calls Quality-oriented teaching of programming. The idea is to think about succeeding in the class in terms of number of programs completed, rather than achieving a passing grade on all or most homework assignments.

I haven’t read Anthony’s paper yet, but am looking forward to it.  I’ve tended to believe that the two humps are caused by a priori knowledge, but missing out on the early stuff would lead to a similar effect.

Critical thinking? You need knowledge – The Boston Globe is a piece by Diane Ravitch, which speaks to some of our recent discussion about the drivers of innovation.  “The intelligent person, the one who truly is a practitioner of critical thinking, has the capacity to understand the lessons of history, to grasp the inner logic of science and mathematics, and to realize the meaning of philosophical debates by studying them.”

The last couple of posts in this blog have generated some wonderful response posts.

• Alfred Thompson wrote a post about what leads to change in computing education. He makes some intriguing predictions about the future of computing education at the end of his post. (The tie to databases got me thinking.)  He agrees with me that, historically, the innovations which have taken root have grown from well-known institutions.  What I found most interesting was the back-and-forth Alfred sees (from his current post at Microsoft) between industry and academic influences on the tools of choice.
• Leigh Ann Sudol wrote a response to Alfred which reflected her frustration with the where the influences are coming from. I strongly agree with her greater goal: “We need to stop arguing about language, tools, etc. and decide what it means for the AVERAGE American to be literate in computing.” She concludes with the economic concerns she sees which limit computer science in secondary education.
• Ian Bogost’s post is in line with Leigh Ann’s, in that he decries the influences on computing education, but he goes further to see it as indicative of an illness within computer science overall. “[O]verall, computing simply doesn’t care about the development of its ideas. It fantasizes itself as a scientific or an engineering discipline, but throws the baby out with the bathwater (even the purest of sciences acknowledges that its ideas arise from the complex flows of history).”  Ian wants computing educators to engage in learning methods that recognize computing as a liberal art (an argument I agree with, and have also made, though not nearly as eloquently).

All three of these posts are, in a sense, complaining about what is driving computing education.  I wrote my original post as a reflection on what has driven change in the past — purely an historical analysis.  The response we’re reading here is, “But that’s not what should drive change in how and what we teach.” Are these influences unique to computer science?  Leigh Ann and Ian call on Biology and Mathematics, respectively, as offering alternative models.  Computing may be more driven by industry than some other fields, but I suspect that these drivers are broader than just computer science.

How do we change what influences our practice?  I’m a fan of Larry Cuban’s work, particularly, “How Scholars Trumped Teachers.”  Cuban analyzes the last 100 years of American Universities and concludes that research wins over teaching.  American universities are set-up so that research and all that goes with it (e.g., focus on funding, publication, and creation of intellectual property) will always dominate attention to education.  Change is possible, but we may have to change our underlying assumptions about what the American University is and what it means, and then change the structure to match the new beliefs.

In this blog, we’ve talked about Lijun Ni’s research results, that suggest that changes that teachers make in their classroom is most influenced by their personal excitement for the change.  We’ve also talked about the fact that research results actually influence teachers very little.  What I’ve been wondering about lately is, “What influences the teacher excitement?”  I don’t have any answers, but I’ll lay out some ideas and let the commentators help us tease out importance.

• Languages.  Computing teachers get excited (even passionate) about languages.  You can tell the story of computing education’s development in terms of the languages that predominate, e.g., Pascal, C++, Java.  The most common question raised over a beer at SIGCSE is probably “What’s the next big language?”   Dijkstra famously believed that the language in the first choice was critical to avoid “mutilating” a student’s thinking about computing.  Why do we believe that?  Why should the first language matter so much?  Here are two hypotheses: (1) Since computation is not obvious in the world around us, students have no idea what computing is when they walk into their first programming language, so whatever model of computation that’s embedded in that first language is the first model that students will meet. (2) As educators, we tend to “teach the language.” Thus, the features of the language become the curriculum of the first course, for better or worse (I tend to believe the latter).  Not sure why we made programming language designers into our curricular designers, but any tour of a Java CS1 textbook (and it’s growing heft) suggests that we have.
• Authority. Pascal came from ETH and Niklaus Wirth. Structure and Interpretation of Computer Programs came from MIT.  Java came from Sun Microsystems. Would Pascal have had as much influence if it had been developed by somebody at a small liberal arts college?  It could have been developed elsewhere — Pascal is a small language, really.  Would SICP have had as much influence if it had come from somewhere else?  Authority does influence us, much as we like to pretend it doesn’t.  Could we imagine an open source textbook or language becoming the dominant text or tool in introdocutory computing courses?  I doubt it — we attend to the inventor and the institution.
• Textbooks.  When I look over the list of awardees for the SIGCSE Outstanding Contributions to CS Education, I see lots of mention of textbooks.  But when I think over influences on CS education, I don’t really see textbooks as a major influence of change. It’s necessary for change — Pascal would not have taken off in CS1’s if “Oh Pascal!” wasn’t out there and available.  But Pascal’s influence extends beyond that textbook.  I only know a few C++ textbooks, and none dominate my (scarce) knowledge of C++ using schools, but I do know that C++ is really popular.  Probably the most influential CS textbook I know is SICP.  (Surprising that neither Hal Abelson or Gerald Sussman are on the SIGCSE awardees list.)  Is that the influence of the book, or of the curriculum?  Hard to tease those apart.
• Tools.  While there have been lots of IDE’s, visualization tools, animation tools, etc., few of them stand out for me as major change agents.  Alice is one, and Karel the Robot is probably another.  What makes a tool successful at creating change?  Why did Alice succeed?  I suggest that it met a need (a tool for a CS0-like course) when such a need arose, and it was supported by the right authority (Randy Pausch at CMU).  It’s hard for a tool to change CS1’s because CS1’s already exist and those needs are being met (by something).  Alice might not have become as popular 10 years earlier when CS was less likely seen as a topic for non-majors or for pre-undergraduate students.

Others? What am I missing?  My first pass analysis suggests that, to make change in CS, invent a language or tool at a well-known institution.  Textbooks or curricula rarely make change, and it’s really hard to get attention when you’re not at a “name” institution.