Programming and the Development of Problem-Solving Skills
On the surface, the argument that students can learn general problem-solving skills from programming experiences seems logical. Programming is a classic problem-solving activity. Descriptions of what experienced programmers do (Pea & Kurland, 1987) are almost identical to more general descriptions of the problem-solving process (Bransford & Stein, 1984; Hayes & Simon, 1974). As the programmer attempts to accomplish a programming task, he or she must:
- Understand the task.
- Develop a plan for completing the task on the computer.
- Convert the plan into programming code.
- Evaluate the extent to which the program functions as desired and modify the program when necessary.
Do students learn to become better problem solvers because they have spent time learning to program? Providing a direct answer to this question is difficult. Various reviews of the research attempting to summarize this issue have not reached a unanimous conclusion (Keller, 1990; Pea & Kurland, 1987b; Salomon & Perkins, 1987).
Reasons for Conducting an Overview of the Research
The body of research about the relationship between programming and the development of problem-solving skills is important for several reasons.
- Becoming familiar with the research will help you when you are trying to make decisions about how to integrate technology effectively into your classroom. If you decide to provide your students with programming experiences, for example, you should attempt to determine whether programming benefits them, what the benefits are likely to be, and which approaches to teaching programming seem most productive.
- The research literature provides an example of the evolution of theory and related ideas about classroom applications. Consideration of this body of work demonstrates that the results of research studies can cause recommendations for practice to change.
- Much of the research on programming and problem solving was conducted in classroom settings using the LOGO programming language which is the language we have emphasized here. The impact of LOGO on student behavior is directly determined by the actual experiences of students, not by the potential experiences that are never realized.
- The studies seem to lead to recommendations for practice that mesh with many of the ideas developed in the second chapter (Meaningful learning in an information age): cognitive apprenticeship, authentic tasks, and learning for transfer or application.
Early expectations of LOGO may have been overly optimistic. When new and promising educational ideas do not deliver as advertised, the educational community often drops the ideas and looks for the next innovation. We agree with those who caution against this reaction and suggest that educators treat the educational application of LOGO itself as a LOGO program that does not work as anticipated. Even an inexperienced programmer realizes that a complex program often does not run on the first attempt, and the appropriate response should be to evaluate the program and its assumptions carefully rather than abandon the work that has been completed.
The Transfer Issue
Transfer implies that what is learned in one context can be applied in a different context. Context can have various meanings and one interpretation contrasts near and far transfer which differ as a function of context similarity. An example of far transfer that would apply here proposes that what is learned about solving problems while programming can be applied in solving other problems that do not involve programming. As we note in the first two chapters, the development of higher level skills are considered of great value as 21st century skills and learning experiences that can contribute to the development of problem solving skills are likely to receive a great deal of attention. We regard this as an optimistic and possibly overly optimistic goal for classroom programming experiences.
Making the case for far transfer is difficult. Some researchers (e.g., Detterman, 1993) claim higher order thinking capabilities are typically domain specific. You get the gist of his argument from the title of his article - “Transfer as an epiphenomenon”. This position might be interpreted as “with experience programmers may become more proficient at the problems programmers attempt to solve, but this improvement will not make programmers better at solving other types of problems.” Programming would represent one domain and other areas (e.g., poetry) different domains. Others disagree, but identify conditions under which transfer is more and less likely to occur. If those who support transfer are correct, it is important to understand the conditions they identify and assure that such conditions are met.
You may not feel that it is important for those promoting K-12 programming experiences to demonstrate that learning about programming results in something more than the development of programming skill. Making broader claims is seldom required in evaluating the school curriculum. For example, we learn about history because we assume it is important to know history and not because we have been convinced that careful scrutiny of historians conclusions might be a way to develop critical thinking skills. However, having made this comparison, it might also be claimed that how history is taught could possibly determine whether learning how to think critically in evaluating accounts of history is developed in addition to learning what prominent historians conclude. Perhaps to break into the daily lineup of school offerings, the advocates for teaching programming feel the need to suggest that computing thinking can be applied in many contexts.
Conditions for Low- and High-Road Transfer
Transfer can occur in two ways, sometimes referred to as low- and high-road transfer (Salomon & Perkins, 1987). In low-road transfer, behavior is practiced extensively and in a variety of situations and learned to the point of automatization. Automatized behavior is behavior that a person has learned to the point at which he or she can complete a task without thinking about it. For example, if you drive or are a competent typist, you have practiced skills extensively and in a variety of situations and have likely automatized behaviors related to typing and driving. When you type the letter q, the fact that the little finger on your left hand moves straight up one row is probably not something that is conscious.
In high-road transfer, skills must be deliberately transferred from one context to another. Two requirements must be met. First, the individual must be capable of re-representing the original skill at a level that will include a greater range of cases than was covered by the context in which the original skill was first acquired. For example, if a student both observes from experiences with programming and is capable of explaining that it is often useful to take a complex problem and identify individual tasks to be accomplished, the student has re-represented programming knowledge in an abstract and verbal fashion that would apply to many tasks. Second, the student must be willing to make a conscious effort to use past experiences to attack current problems. Such an approach requires both motivation and metacognitive skill.
Identifying whether studies met the requirement for either high- or low-road transfer turned out to be an accurate way to predict whether the studies were successful in demonstrating the transfer of problem-solving skills (Salomon & Perkins, 1987). To summarize, when students did not
- spend enough time programming to develop a reasonable level of skill or accumulate enough diverse experiences,
- consider and discuss how they solve problems when they program, and
- consider how the problem-solving skills involved in programming might apply to other domains, the research studies were unlikely to demonstrate that students could transfer programming skills to other areas.