Communications of the ACM
How We Teach Introductory Computer Science Is Wrong
Georgia Institute of Technology professor Mark Guzdial
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 assigned several papers on the topic (see the papers in the References) to my educational technology class. Those papers have been influencing my thinking about how we teach computing.
In general, we teach computing by asking students to engage in the activity of professionals in the field: by programming. We lecture to them and have them study texts, of course, but most of the learning is expected to occur through the practice of programming. We teach programming by having students program.
The original 1985 Sweller and Cooper paper on worked examples 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 the idea that we should best teach problem-solving by having students solve problems.
The paper by Kirschner, Sweller, and Clark (KSC) 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." What exactly is minimal instruction? And are they really describing us? I think this quote describes how we work in computing education 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 seems to reflect our practice, paraphrasing as, "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.
There have been rebuttals to this article. 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 been reading) says that expecting students to program as a way of learning programming is an ineffective way to teach.
What should we do instead? That's a big, open question. Pete Pirolli and Mimi Recker have explored the methods of worked examples and cognitive load theory in programming, and found that they work pretty well. Lots of options are being explored in this literature, from using tools like intelligent tutors to focusing on program "completion" problems (van Merrienboer and Krammer in 1987 got great results using completion rather than program generation).
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. Intermediate 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.
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.
References
- 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.
Comments
Cay Horstmann
Aren't you making a rather large leap equating "How we teach programming" with "minimally guided instruction"?
In my experience, most skilled CS1 instructors teach problem solving skills, give "code comprehension" and "code completion" work, and package programming assignments so that students have a design roadmap, implementation hints, and starter code.
Is there anyone in the CS ed community seriously advocating "minimally guided instruction" as a viable strategy for learning how to program?
Mark Guzdial
Hi Cay! The picture you're describing of effective CS1 instruction is terrific, and is certainly *not* minimally guided instruction. However, your experience differs from mine. Most CS1 courses that I see consist of lectures, programming assignments, and quizzes and exams. Notice that at SIGCSE, we have a perennial favorite session on "Nifty Assignments." Reviewing those projects (http://nifty.stanford.edu), I rarely see design roadmaps, implementation hints, or starter code. Have you ever seen a similar panel on "Great Code Comprehension Assignments" and "Swell Code Completion Challenges for Student Practice"? I haven't, but I wish we did. I'd like to see us develop a wide range of different kinds of educational activities for computing students. We have some (e.g., www.problets.org and TuringsCraft.com). We need more.
Ariel Stulman
I've taught intro courses for a couple of years now. I always tried to veer off the "syntax" route and stick with the "algorithmic" approach (simple algorithms, of course). I've been using it as a tool to "get them thinking" instead of mimicking. And yes, we have been showing them sample code, many times written during the lecture, pointing out problems in original design, and going back to fix those problems (a "spring-like" methodology).
I've tried, to show them code (reading before writing). But since no problem is similar to another (unlike a lot of the math courses they take in conjunction - Calculus 1 and 2, linear algebra, finite math, etc. - where they are given some kind of "template" and then they go ahead and "do it" many times), they are always baffled with the "next time". Thus, I'm not sure an algebraic experiment is a litmus test for this subject.
Students (and so does the author of this blog) expect that they be given information they can "mimick", just like they do in their math courses. They resent the fact that this course is different, and they need to come up - every time - with a similar, but different, solution. But is mimicking ("reading before writing") the way to learn something that is a bit different every time.
I always found that the class is split into two groups: those that enjoy the challenge and those that resent it. Those that understand why CS1 is different than Math1, and those that complain because they don't understand.
A way of getting to this latter group would be greatly appreciated.
One last point: The slogan "reading before writing" is catchy, but I don't think it's really the way we learn. "Talking before reading" would be more accurate. When learning a new (natural) language, one must learn to speak it before he attempts to read or write in it. It's the way toddlers learn as well. Otherwise, one doesn't know what he is seeing.
I'm not sure what the analogy would be as far a learning to program ("syntax before programs" ?!?!).
Arend Rensink
It seems to me you are implicitly equating "teaching programming by having students program", or more generally "teaching problem-solving by having students solve problems", with "minimally-guided instruction". I think the two need not be the same.
I have always strongly disbelieved that you could teach anyone swimming by throwing them into the deep, or equivalently, teach them anything at all by having them struggle on their own. I have never understood why anyone would think that this is a good way to convey insight or skills. However, not having students practice those skills that they have to learn is just as obviously wrong.
The answer is quite obvious, and in line with how subjects are taught in virtually all of our courses (at the University of Twente): you show how things are done on the basis of a few examples, then let students solve similar problems on their own. You walk around and help them when they are stuck. Then you set them harder problems that they have to solve with less guidance.
I think it is sad to see that this obvious, common-sense approach is apparently so far from the norm that I am only the second in this thread (after Lewchuk) to even make this observation.
Ralph Johnson
It is fine to learn programming on your own. Millions of people have done so, including most of those who took a course in introductory programming. Most teachers just teach the syntax and demonstrate how to write programs and let people figure it out on their own. This is fine for those who are capable of figuring it out, but it fails those who really need a teacher. We need to learn how to teach programming, not for those who can figure it out on their own, but for those who can't.
Mark Guzdial raised the question of why people haven't followed up on Linn and Clancy's work. I think this was partly because the material they developed was all in Pascal, and Pascal was just falling out of favor then. Another reason is that it is very hard to get old teachers to pick up new methods. You need to give them all the materials they need, to give them a system that they can use. Inventing good case studies is hard. Teachers are busy. Many of them don't know enough to construct good case studies, the others are not sure it will help.
Displaying comments 11 - 15 of 15 in total