Communications of the ACM

debug programs, students need to develop a mental model of the notional machine. We have a poor track record in helping students be able to trace and predict program execution, as Raymond Lister has been exploring in his research (see http://bit.ly/2n7A8Xr).

Maybe our students don’t develop enough understanding of the notional machine because our introductory courses don’t make program understanding a key learning goal. Students need to understand, but they want to build. We can teach for understanding, but that’s harder to do in authentic, complex learning situations, as Simon and others have pointed out ( http://bit.ly/2nFRuGZ).

Perhaps in response, many introductory computer sciences take a middle ground and focus on problem-solving (see examples at http://bit. ly/2oVyXXu and http://bit.ly/2n7yu80). Some teachers even define computer science as “algorithmic problem-solving” ( http://bit.ly/2nYJhQP, which doesn’t appear at all in the Newell, Perlis, and Simon definition of the field at http://bit.ly/2nFIzpf). Teachers can get students to realize they have to solve problems to create software, so they emphasize how to solve problems with programs and algorithms.

A focus on problem-solving is a rational way to strike a balance between getting students to understand programs and their desire to build. We give students problem statements (describing things to build), and we teach them how to go from the problem statements to a working program. We teach them how to design with objects, and how to analyze problems for the data structures within them.

The problem is that teaching prob-
lem-solving is not the same thing as
teaching for understanding, and em-
pirical evidence suggests it isn’t work-
ing. John Sweller showed years ago that
more problem-solving doesn’t lead to
greater understanding. Problem-solv-
ing creates enormous cognitive load
that interferes with learning to under-
stand ( http://bit.ly/2nAufgV). If we want
students to understand more, we have
to teach for understanding. In my book
Learner-Centered Design of Comput-
ing Education ( http://bit.ly/1JYLeUz),
I describe some of the evidence that
students are not developing an under-
standing of programs and developing a
mental model of the notional machine.
To teach for understanding, we
would give students worked examples
and ask them questions about the ex-
amples, ask students to predict out-
comes or next steps in a visualization
( http://bit.ly/2nAs5xN), or ask students
to solve Parson’s Problems. We would
do far less of giving students a problem
they’ve never seen before, and asking
them to generate a brand-new program
to solve that problem.
At ICER 2016, Briana Morrison, Lau-
ren Margulieux, and Adrienne Decker
presented a replication study showing
that introductory students miss impor-
tant details in problem statements, but
they figure them out when the students
reach their second CS course (http://bit.
ly/2n7BOjH). Morrison thinks it takes
students that long to develop their un-
derstanding so they are more effective
at problem-solving. We could perhaps
achieve better understanding earlier,
but we’d have to teach for understand-
ing. We computer science teachers
tend to underemphasize program
comprehension, because it’s boring
for us—and it’s easy for computer sci-
ence teachers. It falls in our expert blind
spot. A focus on understanding can be
boring for the students, too, because it’s
not about making stuff.
We need a new balance point. We
need to do more to get students to
understand. They need to build, too,
because that’s important for student
motivation. We need to create learn-
ing situations where we ask students
to practice program reading, to predict
program execution, and to understand
program idioms. More problem-solving
might need to wait until student under-
standing catches up.

Comments

I have to question the assumptions that teaching for understanding is the right goal. There are many aspects in the applications I build that I don’t understand. But I don’t need to.

“Understanding” is such a slippery goal, whether we talking about understanding computers or Shakespeare. It only becomes well defined when we talk about when you need it, for example, to find a bug, or adapt a solution to a new problem. But then we’re back to skills in designing and problem solving as the primary goal.

I do love the notional machine concept though, at least as I “understand” it so far. Which means how I see applying it is thus: to help students when they are struggling in debugging or design, help them articulate and develop a better, partial, locally useful, notional machine.

—Christopher Riesbeck
Hi Chris,
I bet that we would agree that the depth
of the understanding is the question. I use
my computer all the time without thinking
about transistors.

Think about it in terms of Bloom’s taxonomy. The lowest level of learning is simply being able to repeat what was heard. Later levels include being able recognize the right thing and to predict. The highest levels are synthesis and problem-solving. Surely those lower levels matter in computer science. We can’t ONLY expect students to perform at the highest levels. We also have to teach for those lower levels, too.

—Mark Guzdial
Dear Mr. Guzdial,
Many thanks for your article on CS for all.
Being retired, I spare my time with a group
“fighting against school dropping out.” We
receive students after their school hours and
help them doing their homework. It works
fine! I’m planning, may be some times from
now, to introduce them to CS. Your article
inspired me. Again, many thanks!