And here a miracle happens
I was reading a post by Mark Guzdial yesterday (In Praise of Drill and Practice) and was struck by this passage:
[…] we really don’t have much for CS learners before throwing them in front of a speeding interpreter or compiler. A blank editor window is a mighty big fill-in-the-blank question. We need some low cognitive load starting materials, even for the high ability learners.
Hélène Martin adds in the comments:
we owe it to our students to provide early emphasis on computational building blocks rather than jumping straight to high degrees of abstraction. My favorite example: the general concept of iteration is baffling for lots of students and it’s an important tool for writing any sort of program. Instructors often shortchange students by casually presenting iteration as a syntactic element and then assuming its understanding. There’s too much going on in a simple loop to do that (or recursion or any other way of repeating stuff).
This is pretty much what happens. We hand students some tools, explain what they are for and then cut students lose to create something new. It is sort of like handing students some hand tools, giving them some simple lessons and then asking them to create a new chair. We basically expect a miracle to happen in the process.
We don’t do with with other subjects. Take writing for example. We start with letters and move to words. We don’t jump from learning individual words to writing novels. We step into simple sentences, more complex sentences, paragraphs, the essay, and so on. Little by little we build up to more abstract concepts and their execution. And yet we assume that if a student knows how a loop works in theory we can jump into “write a program to print out the song 100 bottles of soda.” We’d like to think that a good student can put the pieces together but can they? Typically some can and many work on code by trial and error and eventually get closer and closer. All the while, they learn bad habits.
We move to quickly I think. I believe I have been guilty of this myself. It’s something I need to work on I believe. And something that will influence any future textbook writing I should find myself doing. But what would that mean? I think we need more exercises. Not complex tasks, though there is a place for those, but simple tasks that reinforce the concepts being learned and gradually develop the ability to string abstractions together to build new more complex solutions.
Maybe also design recipes that let students start with something simple and gradually build it up to something more complex. I have been looking at Lynn Langit and Llewellyn Falco’s Small Basic recipes as samples of how things might work. I really like the step by step iterative process of “growing” a program. There are probably more small exercises that can be created though. It would be helpful to collect some for use. But the key, I believe, is to make haste slowly. By slowing things down and spending more time on really understanding the fundamentals and really understanding the software design process we should be able to save time on actually writing the code.