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
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
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.
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
“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,
I bet that we would agree that the depth
of the understanding is the question. I use
my computer all the time without thinking
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.
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!
Mark Guzdial is Director of Contextualized Support for
Learning at the Georgia Tech College of Computing.
© 2017 ACM 0001-0782/17/06 $15.00
We need to create
where we ask
students to practice
to predict program