http://bit.ly/1qnv6gy October 8, 2009
I have been interested in John Sweller and Cognitive Load Theory (http://bit.ly/1lSmG0f) since reading Ray Lister's ACE keynote paper from a couple years back (http://bit.ly/1wPYrkU). 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. The 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 programs from the basic information on the language, and they should do it in the same way that experts do it." The paper then goes presents evidence showing that this "minimally guided instruction" does not work.
After a half-century of advocacy associated with instruction using minimal guidance, it appears there is no body of research supporting the technique. Insofar 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 is striking is that they basically say, "But not problem-based and inquiry-based learning! Those are actually guided, scaffolded forms of instruction." What is 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 have been reading) says expecting students to program as a way of learning programming is an ineffective way to teach.
What should we do instead? That is a big, open question. Peter Pirolli and Mimi Recker have explored the methods of worked examples and cognitive load theory in programming, and found 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 is a bad way to start. Students need the opportunity to gain knowledge first, before programming, just as with reading (http://wapo.st/1wc4gtH). 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 is just not at the beginning.
Overall, I find this literature unintuitive. It seems obvious to me the way to learn to program is by programming. It seems obvious to me real programming can be motivating. KSC responds:
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 does not offer a lot of obvious answers for how to do computing education better. It does, however, provide strong evidence that what we are doing is wrong, and offers pointers to how other disciplines have done it better. It as a challenge to us to question our practice.
I would like to point out a CACM article published in March 1992; "The Case for Case Studies of Programming Problems" by Marcia Linn and Michael Clancy.
In my opinion, they describe how we should teach introductory programming primarily by reading programs, and only secondarily by writing them. I was attracted to this paper by its emphasis on learning patterns of programming. The authors used this approach for years at Berkeley and it resulted in remarkable improvement in teaching effectiveness.
I agree. Linn and Clancy's case studies are a great example of using findings from the learning sciences to design effective computing education. So where is the use of case studies today? Why do so few introductory classes use case studies? Similarly, the results of using cognitive tutors for teaching programming are wonderful (and CMU makes a collection of tools for building cognitive tutors readily available at http://bit.ly/1rXAkoK), yet few are used in our classes. The bottom line for me is there are some great ideas out there and we are not doing enough to build on these past successes. Perhaps we need to remember as teachers some of the lessons of reuse we try to instill in our students.
From my experience, the "minimal guidance" part is probably the key. One of the best ways to master a new language, library, "paradigm," etc., is to read lots of exemplary code. However, after lots of exposure to such examples, nothing cements that knowledge like actually writing similar code yourself. In fact, there's a small movement among practitioners to create and practice "dojos" and "koans" (for example, in the TDD and Ruby communities).
Another way to think about this: Why does CS expect students to learn to write before they learn to read?
This interests me as a lab teaching assistant and paper-grader for introductory Java courses. Students I help fit the mold you describe. They do not know anything about programming, yet they are expected to sit down and do it. It is easy material, but they just do not know where to start.
K. Wampler, are you familiar with Richard Gabriel's proposal for a Masters of Fine Arts in Software (http://bit.ly/1KeDnPB)? It seems similar in goal. Clifton and Jake, agreed! I do not mean no programming in CS1—I believe we need hybrid approaches where students engage in a variety of activities.
I have always taught introductory programming with first lessons in reading programs, understanding their structure, and analyzing them. It is a written language after all. We usually learn languages first by reading, then by writing, and continuing on in complexities of both. Unfortunately, it frustrates the "ringers" in the class who want to dive right in and start programming right away.
I fail to see why this is considered surprising or counterintuitive. Look at CS education:
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. http://bit.ly/1BASeOh
Sweller, J., and 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. http://bit.ly/1rXzBUv
©2015 ACM 0001-0782/15/02
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2015 ACM, Inc.
I see some inconsistency in the arguments used in the discussion. From one side, we teach students reading by reading, but on the other side, some people question when we teach problem-solving by solving problems. Reading is a general skill and competency, basic and used in mastering other skills. Program-texts are greek for most beginners in programming, they should first learn "vocabulary" of programs, that is basic structures/constractions used in programs and, more important, they should learn meanings of this constructions. Simple reading programs does not help very much and teaches nothing if the context is not considered (parameters, instructions which precede and follow etc.).
Today we should also remember that visual programming (using graphical blocks), as the first step in programming, changes the meaning of "reading" programs. In fact, the Scratch environment is designed to use and modify other programs when building our own programs. Therefore, "reading" and "writing" such programs is a continuous integrated process of reading and writing, Then when students change their visual programming environment for textual, the same approch remains - they make use of subroutine libraries or programs found in the net to write their own programs
Maciej M. Syslo
I'm a big believer in empirical evidence. When it comes to learning, we need to test our models with experimentation and not rely on thought experiments. For example, students don't learn to read by reading. They learn to read by being immersed in a textual culture, by having parents read to them, and contrary to some expectation, by writing -- see this report: http://www.readingrockets.org/articles/researchbytopic/36871. The empirical evidence suggests that reading problems can help develop problem-solving skills more than just solving more problems, but at a certain level of experience -- see the work on expertise reversal effect for where it's more important to problem-solve than to read worked examples https://en.wikipedia.org/wiki/Expertise_reversal_effect.
Thus statements like "Simple reading programs does not help very much and teaches nothing if the context is not considered" need to be tested. We cannot assume that they are true on face value or by thought experiments.
Displaying all 2 comments