Teaching Programming

Programming has been described by many authors as the new Latin of the school syllabus, a kind of mental whetstone for developing minds. As such, it was assumed that students would develop their general problem-solving skills through learning programming. However, reports from teachers of programming and results from some empirical studies now suggest that the teaching of programming has created significant difficulties even for university students, and has failed to catalyze the development of higher order thinking skills.

What has gone wrong? It is wise for teachers of IT to review  some of the challenges of both teaching and learning programming. The programmer's objective, for beginners and expert alike, is first to specify a detailed plan that can be carried out. That is, the programmer has to decompose the initial task. This is not trivial: Many people are quite unable to say how they perform certain tasks. For instance, many students in introductory programming classes are unable to explain how they are able to select the smallest of a series of integers. 

Next, the programmer must map this plan into the constructs of the target programming language. There are two points to be made about this mapping process.

1.      First, for the process to be "clean," the programmer needs to have a very clear idea of the abstract plan and of the constructs available in the programming language. One study of beginner programmers showed that many beginners had very fuzzy notions about a programming language—substantial misunderstandings had occurred with regard to virtually every construct in the language.

2.      Second, task decomposition and program coding are not as neatly decoupled as we might think. A simple example: If arrays are not available in the target programming language, then a plan that assumes this capability would be badly flawed. A thorough knowledge of the facilities provided by the programming language is needed even at the stage of formulating the task plan. 

Debugging a program is similarly complex and demands a variety of skills, including an ability to coordinate information derived from sources such as error messages, the program plan, the program specification, and the actual code.

There are some resources to help:

1.    John Anderson and Edward Skwarecki's "The Automated Tutoring of Introductory Computer Programming" demonstrates that intelligent computer-assisted instruction (ICAI) technology can be a more effective way of teaching introductory programming courses—for certain populations.

2.    Elliot Soloway's "Learning to Program = Learning to Construct Mechanisms and Explanations" challenges conventional wisdom by taking a fresh look at assumptions about the art of programming.

3.    Soloway advocates a more explicit approach to the teaching of problem-solving skills, which is based on the actual skills experienced programmers use in addressing real tasks.

4.    "Boxer: A Reconstructible Computational Medium," by Andrea A. diSessa and Harold Abelson, proposes a radically new kind of computational medium—one that would be highly tailorable, and able to accommodate a wide range of users, from a seven-year-old to an experienced nonprofessional.

Recent experiments have suggested that the domain knowledge of experienced programmers is organized in a radically different way from the domain knowledge of beginner programmers; analogous results have also been reported for chess and music. In all cases, experts use larger chunks of knowledge. An important instructional question is how to bring beginners up to the expert's level of domain knowledge. Aside from teaching details of the syntax and semantics of a particular programming language, it is necessary to explicitly and concurrently explain why and how programs work, the goal of any given program, what plan segments are, strategies for decomposing tasks, rules that well-formed programs adhere to, and design strategies. If followed, this approach would produce several radically different types of programming courses.