Computer programming teachers often report a polarization in their classes. Students either “get” programming, or they don’t, and there’s little in between. If you plot average grade against number of students, you end up with a double hump. Lots with a low grade, and lots with a high grade, and a gap in the middle.
This image comes from http://blogs.kent.ac.uk/mik/2009/09/quality-oriented-teaching-of-programming/.
Here are some ideas of the causes of the double hump.
Some kids get it, some don’t.
I think there is probably an element of this going on, however unpalatable the idea is.
Programming is highly self-amplifying.
This idea says that, more than any other subject, computer programming is highly hierarchical. You can’t progress if you haven’t got the building blocks. If you don’t get an early idea, you will struggle with later ideas. Since, necessarily, not all students will get all ideas early on, there will always be a bisection of the group; ones who got it early on, and ones who didn’t. Hence the double hump.
Personally I don’t give this idea much credence because it doesn’t explain the observation of many computer programming teachers that some students still don’t get it even after you’ve gone right back to the start with them and spent lots of time one to one. In my classes, for instance, I will generally start off with a traditional mini-course lasting about 4-6 weeks covering topics such as variables, data types, control structures, etc. Once the stronger programmers have emerged, I will give them an independent project to work on, while I go back to the beginning with the others. The self-amplifying theory would predict that half of this new, smaller group would now “get it” and join the stronger group. But that doesn’t happen.
Prior knowledge and course expectations
Some of my students have programmed before and they got a thrill (like I did) when they first got the computer to say “Hello World”. They themselves have chosen to do the computer programming course because they have some prior knowledge, they know what to expect and they know they like it.
Other students choose the course because their parents tell them to, or because they have a vague belief that studying computers will be of some general benefit later in their lives.
I think this may contribute to the double hump effect because those who have some experience race ahead, and those without experience have to overcome a lack of true motivation and often a sense of disillusionment when computer programming turns out to be different from what they expected.
Computer programming favours a certain type of learner
Let’s say that you teach some very basic programming, culminating in the example algorithm “finding the maximum value in an integer array”. Once you’ve done that, do you then teach your students how to find the minimum? Then how do find the sum? Then how to find the number of occurrences of a particular value? etc, etc. No. You can’t teach every possible algorithm. You give students the building blocks and then encourage them to apply their knowledge to new problems.
In this way, I suggest that there is actually very little that the teacher imparts to the student in a programming course. It’s for this same reason that, once you have mastered one language, it really only takes a couple of days’ work to be productive in an entirely new language. Once you’ve taught the basic concepts, most of the course is practical problem-solving.
What has this got to do with the double hump? Well perhaps there are different ways in which students learn and perform in class, and computer programming discriminates between them sharply. I will try to illustrate by describing two mathematics students that I teach. One of them likes to do problem after problem. She screws her face up when she doesn’t understand my explanation, discusses and argues with her friends, hurriedly flicks through the textbook, and then declares “It’s ok, it’s ok. I’ve got it.” When we do project work, such as producing a poster, or a news report, her mathematics will generally be correct, but she will lose marks for presentation. Another student is very quiet and hard-working. She produces beautiful notes, reproducing every equation and diagram that I put on the board. She seldom asks questions. In project work she sometimes makes conceptual mistakes with her mathematics, but she recoups her lost marks through excellent presentation. Both students are on a B+ grade.
How would these students fare in a computer programming course? Well, the point I am trying perhaps rather clumsily to make is that you cannot get by in computer programming by copying and reproducing the teacher’s notes, and there are seldom any peripheral activities (such as poster design) that can mask a problem with the core competence of the subject. (You could introduce these activities of course, but you are not solving the double hump problem, you are just moving the subject away from computer programming — see the next section.) Instead, students have to be problem-solvers with a desire to understand concepts on their own terms. That’s why I think that two students who could be on the same grade in some subjects, can still be polarized when it comes to computer programming.
To go back to my original example on the impossibility of teaching every possible algorithm, the first student develops some true insight when studying the first algorithm and can apply this to a new problem. The second student, when faced with a new problem, just says “But you haven’t taught us that.”
Computer programming is one-dimensional
I alluded to this in the last section. My wife is a geography teacher and one of the reasons she loves geography is that there is such a wide range of skills that students can learn and be assessed on. Geographers habitually write essays, produce graphs, draw diagrams, debate, do mathematics, make speeches, create models and do presentations. Some students are good at some things, other students are good at other things.
Geography doesn’t suffer from the double hump because the range of variables averages out and you end up with a rather more easily explained single hump.
Perhaps we could bring a wider range of skills into computer programming classes? Answers on a postcard.
What to do about the double hump?
What is certainly true is that we can’t plough on with a course, trying to teach everyone the same things, at the same pace, and hoping it will work. So it seems very obvious that we should introduce measures to allow students to work at their own pace. My own feeling is that it is probably unmanageable to allow high school students complete free rein on how they study, but certainly splitting the class into two or three or even four groups, each working at different levels, has to be a basic requirement.
I also think that students should be graded on standards and competencies, rather than given letter grades. Students should be allowed to achieve Level I, Level II or Level III on a course, indicating how much they mastered, rather than how well/badly they did on the course. Getting a Level I on the course says “You started this course from scratch and you have achieved a mastery of the basic concepts.” This is very different from saying “You tried to do the same as another student and you got a C but they got an A.”