Observing Thinking

Observing Thinking
Observing Thinking

Thursday, May 8, 2014

A Recipe for Disaster? Part 1

Of late, there has been much in the media about teaching young people, especially women, to code or, in less arcane language: to program or write software for computers, for example:

code.org http://www.ted.com/talks/mitch_resnick_let_s_teach_kids_to_code


The primary justification for this enterprise is, unsurprisingly, economic. The logic is simple and specious: computer technology is ubiquitous so there are lots of jobs related to computers, therefore we can help solve the current lack of jobs problem by scooping up our youth and training them to become programmers. I believe this approach has a strong potential for producing snafus even worse than the initial rollout of Obamacare. Now please don’t think that I believe that teaching kids to program is a complete waste of time. I strongly believe that programming is a rewarding and empowering activity that combines the logical thinking of the mathematician, the creativity of the poet, the pragmatism of the engineer and the patient stubbornness of the detective --- so it is definitely worth studying. But I do worry that we’re pushing this bandwagon for the wrong reasons.

When I first came to teach Computer Science at SUNY in 1978 I had the same idea that it would be useful to teach young people how to program but for entirely different reasons. I thought that learning to program would an excellent technique for teaching problem-solving methods to college freshman. I believed that programming is an empowering, creative activity that, like any good creative activity is immensely absorbing and satisfying.

Things went swimmingly for several years resulting in several papers that I delivered at regional, national and international conferences. But I was starting to have doubts. The question that kept nagging at me was: “Does programming develop general problem-solving skills or is it the other way round --- students who already have good problem-solving skills tend to be good at, and hence drawn to programming?” I could easily see that the good programmers in my classes also had good problem-solving skills but I wasn’t sure which one was the cause and which was the effect. Then, by chance I attended a talk by Edsger W. Dijkstra at Union College and posed my nagging question to him. I, like most of my colleagues, considered Dijkstra, one of the giants of Computer Science. Amongst his many accomplishments, he spearheaded the development of Structured Programming, a methodology that would allow a programmer to produce more reliable programs. He was a great believer in the idea that one should develop a logical plan for an algorithm (the essence of a program) before sitting down and doing the coding. In any case, his answer to my question was upsetting; based on his own experience, he believed that good programmers came to programming as already-formed, good problem solvers. If correct, the very foundation of my research for past several years was fatally flawed and I had perhaps done a great disservice to many of my students.

On further reflection, however, I realized that there was no hard evidence in either direction. The main problem is getting everyone to agree on precisely what they mean by “problem solving” and even if there is some overlap across different definitions there still remains the question: Is it even possible to teach general problem solving? A strong case can be made that while the problem-solving skills of an engineer and a computer programmer seem to be very similar, it is much harder to show the correspondence between a poet’s and an engineer’s problem-solving skills. And, as a formerly trained mathematician, it seems intuitively obvious to me that there is a great deal of overlap between a mathematician’s, physicist’s and poet’s problem-solving skills. At the same time, I noticed that every single one of the students who dropped the course gave me not only the reason for dropping it but hastened to add, “...but it really improved my appreciation for just how difficult it is to write software.” To which I would add, “Yes! --- and especially large software projects like operating systems and even spreadsheets. “ This is still true today: no matter what language you are coding in, it is extremely difficult to write clear, coherent, reliable and economical code. More next month.


  1. You can teach someone to solve problems by leading the person to discover by themselves that they can do it. The satisfaction generated when their efforts finally succeed changes their attitudes towards problem solving. Unfortunately, in colleges we get many students with no motivation and feeling that computer science should not involve much thinking. This, in combination with the weakness in mathematical and reasoning skills tempts colleges to lower their expectations to maximize enrollment. Colleges need not to lower the bar in the degree of difficulty of the challenges posed to students, and at the same time providing them with resources and opportunities to succeed. We would like to improve the quality of enrollment and not only the quantity. Teaching involves a lot of "coaching" in the sense that we need to raise low self-esteems, even by putting students on the spot by expecting them to solve a problem, giving as many hints as necessary without revealing the complete solution, and rewarding them generously when they reach it. Problem solving in these areas is pretty much the same thing: devise a notation, analyze small cases, relate to previous knowledge, or even better, think outside the box and try new ideas. Test in a few particular cases, generalize, and prove. This kind of teaching requires not only much preparation and time, but a lot of personal involvement, and you can do it only with a few students. But those who experience these things will never forget them.

  2. Yes. I agree with your comments --- mostly. I found that, in a lab situation, when a student had a question, my best strategy was to first ask the student the question, "Do you want me to help you figure it out yourself, or do you just want me to tell you the answer?". However my secret agenda was to lead them into asking "just tell me the answer" if the problem was a missing semicolon or the equivalent and to help them figure it out otherwise.

    I've always thought the lab environment provided the best teaching/learning situation. When the student raises their hand, they are ripe for learning --- they actually pay attention to what you're saying; whereas in a lecture, not so much. I have come to realization that a lecture is only an answer to a question that the student has not asked.


Search This Blog