(This is a copy of a message I sent to the Conference of Professors of Computer Science. One reply recommended that I send it to your list, as people interested in the psychology of computer programming. Advice gratefully, even greedily, received.) Executive summary: Students learning to program typically divide into two populations: those who can easily learn, and those who can't. Teaching techniques and curriculum innovation seem to have no effect. Are there any effective ways of testing student aptitude before entering the course? ---------------------------------------------------------------- Because of the illness of a colleague, I've recently returned to the activity of teaching an introductory programming course. It isn't an undergraduate course, but a conversion MSc. That makes a difference, because these students are hard working and highly motivated: they pay their own way, for the most part, and really want to succeed. But, like our undergraduates, they haven't been filtered by previous educational experience -- that is, they don't have a background which has picked out the programmers from the rest. Their motivation is financial and social: they want a job which pays well, and they know that IT/CS/programming skills will bring it. This coupling of relatively rich financial awards with an educational culture which doesn't previously test for whatever it is that successful CS practitioners have is dangerous, and it distinguishes our teaching experience from that of most of our HE colleagues. The A-level (or the BTEC etc.) experience mean that mathematicians, physicists, chemists, biologists, humanities, foreign languages (and to a large extent engineers, medics) get students who have selected, if not always for something they can do, then for something they are interested in and have some experience of. The A level in our subject doesn't do that: programming is undertaken there as an advanced form of copying and/or form filling, and the experience doesn't separate those who can from those who can't to any significant degree. Here, for example, is a histogram of the results of a diagnostic test at the end of week 5 of a Java course. This is a double-unit course (half the students' time for one semester). Note the bimodal profile. This is quite usual in all introductory programming courses that I have taught and/or observed over the last twenty-five years. 0-4 4-9 xx 10-14 xxxxxxxxxxx 15-19 xxxxxxxxxx 20-24 xxxxxxxx 24-29 xxxx 30-34 xxxxxxxxxx 34-39 xxxxxxxxxxx 40-44 xxxxxxx 45-50 xxx There are slightly more in the upper hump, and they can be said to be doing well. Those in the lower hump are not. It's now week 9 of the course, and most of them are still finding difficulty in writing a simple class definition. They are working hard, and some are making slow progress, but they have great difficulty in understanding (for example) the notion of a variable, of assignment, of choice, of evaluation, ..... Just in case you are thinking that this is about the difference between those who can write programs and those who can't, I can assure you that the lower group can't read programs either. It's alright to be a CS practitioner who can't write programs very well, provided you are Gordon Plotkin (hit me, Gordon, if it isn't true :-)) or someone, but if you can't _read_ them either, then you've really had it. In my youth, which I'm sure I have now left, I used to imagine that there was something that could be done about this. Either there was some magic curriculum which would make programming obvious to all (hence one book, now sunk without trace) or/and there was some teaching technique which would get stuff across and produce a normal normal curve (hence a lot of grey hairs, a lot of late nights, and some exhausted exasperated colleagues). I'm now too old to fool myself any longer: there really is a problem, and I'm getting desperate. One thing that is compelling me to think hard about this problem is cohort studies. We are to be measured and judged on the proportion of students who enter our institutions and graduate within three years. (And a good job too, I say.) But those cohort studies won't take account of bimodal achievements in CS, because everybody knows that universities are selective institutions and therefore receive capable students and should have very low dropout rates. Nobody imagines that a high proportion of students are hard or impossible to teach. What I wonder is this: does anybody have any recent experience with aptitude tests? I'm against them in principle, because I believe that they measure existing educational attainment, but I'm prepared to try ratio of inside leg to length of nose, or waving a pendulum bob over a list of names, if only it works. Anything to avoid the disappointment of cohorts of students (and of teachers like me). I know there are other things we can try. Slowing the course down has little effect, and just bores the faster group. Dropping standards further is out of the question (none of us would do that would we? oh no!). Perhaps we should run two CS degrees at undergraduate level, one about programming and the other about something else -- but that doesn't help the entrants to the conversion MSc, who only have a year and can't afford to change direction within it. Can you help? Please don't tell me that all your students learn to program, because I won't believe you (and I'll report you to the QAA if your message isn't anonymous -- just a joke!). Please don't tell me that language X makes learning to program easy for all, because I don't believe in Santa Claus any more. Please _do_ tell me that you use aptitude test A from publisher P and it works perfectly. Or that an inside leg / nose length ratio of less than 7 is what makes a good programmer. Or a photocopy of Joan the Wad if that's what works for you. Help! Richard Bornat
