Coached Program Planning (CPP) is a
dialogue-based tutoring style intended to elicit a pseudocode-style
solution to introductory level programming assignments from
students. Typically, students are given a printout or webpage and
that is the end of the support until they seek help (commonly with a
poorly written program in hand). In contrast, CPP is intended to
provide support at the earliest stages of programming (problem
understanding and solution planning), leaving the actual implementation
up to the student.
The most fundamental aim of CPP is to get the student to both
understand the problem and make essential observations necessary to
write an algorithmic solution. A basic claim of this research is
that (unsuccessful) novices often fail in this respect. The
reader of these dialogues will notice the tutor pushing the student to
think abstractly and to generalize from their commonsense understanding
of the problem. A variety of tutoring tactics are used to do
this, and these are currently being classified, coded, and generalized
(when possible). A few examples are seen in this corpus sample
including
open-ended questioning,
completion-questions,
socratic-questioning,
asking about the state of the code,
and the use of
examples (the
seemingly most powerful technique).
Context of the Tutoring Sessions
Throughout the tutoring sessions, the reader should be aware of the
following:
- The program in question
for the dialogues below is the Hailstone
Program, which involves the use of variables, conditionals, and a
loop. It is a non-trivial assignment typically given in the
fourth or fifth week of an introductory programming course (CS0
level). The reader is encouraged to become familiar with this
assignment before reading the dialogues.
- The pseudocode is not visible
- only the dialogue. You will see the text of the steps as they
are created, and see the dialogue utterance "(tile placed)" to indicate
that the student placed a tile in the pseudocode (a tile holds a step),
but that is all. I intend to improve this later by providing
links to screenshots at each step, or something similar.
- A secondary purpose of CPP (not mentioned in the SIGCSE 03 paper)
is to provide the student with a staged
program plan, meaning a sequence of programming goals such that
the student can write a program to solve a sub-problem, then gradually
add code to accomplish other goals, until the program is
complete. In the dialogues, you will hear the tutor and student
talking about taking a snapshot.
In the interface, this has the effect of freezing the tiles and showing
only the text (making it appear like traditional pseudocode). To
continue working, and a copy of program appears in a new tabbed window.
- At times there were technical problems - some sessions crashed
early, others there is apparent communication delays, etc. These
are rare, but present.
What Happens in the Tutoring Sessions
Basically, the tutor tries to elicit anything and everything from the
student. In addition, confidence and motivation are always
considered. The tutor (also the author) obviously wants (1) the
student to do as much as possible, and (2) to feel responsible for the
problem solving. These are well known human tutoring strategies
(see the work of Merrill, Reiser, Kulik & Kulik, and Lepper, to
name a few).
Typically, the tutor begins with an easy example and then moves onto
building the code. Notice how the student tends to dive into the
individual steps -
they don't like
to think abstractly. While programming instructors and
textbooks tend to teach top-down design, this is evidence that students
do not think this way (Rist and Soloway both make this point
clearly). CPP can be viewed as a tutoring style that supports the
students desire to think bottom-up, but provides the scaffolding
necessary to help them arrive at a suitable top-down style plan
(although in the form of staged design). The idea is to let them
go with what is natural (to think about individual steps), but to help
them stop, observe, and generalize when it is ideal to do
so.
You will also observe many detailed subdialogues involving, for
example, the condition on the loop, the need for a loop at all, the
need for a new variable, the technique to track values in a dynamically
generated sequence, etc. etc. As mentioned earlier, to elicit
these observations, the tutor tends to ask an open-ended question
first, then based on the judgement of the quality of the response,
either asks follow-up questions, or engages an example. An
example is often laborious for both the student and the tutor, but
nearly always effective. Students love concrete examples (no one
is sure quite why - they just do!), so the general strategy is to use
them when absolutely necessary, and to make sure they are effective by
pushing and pushing until the student says what is being sought.
Another way to view CPP is to see it as training a student to think
algorithmically. When students simulate the desired task (e.g.,
do a Hailstone sequence on paper), it's easy for them. They can
apply the rules, count the numbers, and find the largest. The
problem is that these intuitive strategies are wholly inappropriate for
a program. Since they don't know arrays yet, storing all the
numbers is not a viable solution (and it still doesn't save you from
the searching problem). You will see the tutor refer to how the
student "did it in their head" - this is to contrast the difference
between how humans perform tasks, and how very different that sometimes
is from a generalized, programmed solution. The tutoring
sometimes seems to consist of repeated gentle-nudging towards thinking
more abstractly and algorithmically (i.e., like a programmer).
The Dialogues
There are about 20 Hailstone dialogues in the corpus (other problems
are present, like "Rock, Paper, Scissors", but not yet
available). Here is a sampling of a few sessions:
- C1 -
student struggles quite a bit, lots of examples are used, and quite a
few wrong answers are given.
- A4 -
an awesome student, seems to always say the right thing and understand
the tutor's utterances. This is the kind of student who could
probably write the program from scratch without CPP. There are no
instances of referring to an example in this dialogue (during the
pseudocode writing).
- B2 -
a good student who makes a lot of little mistakes. The tutor is
key here in helping this student to be less careless and to think about
the consequences of certain suggestions and/or step locations.
- B4 -
one of my favorites. This student also gives some questionable
answers, but seems to understand in the end. Note specifically
lines 145-169. This clearly shows the intutive/algorithmic
distinction I referred to earlier. Line 169 is great (sadly, the
student seems to relapse in line 224 by not seeing there is more work
to do on the counting goal, though).
- C3 -
this student struggles quite a bit, and seems to have a hard time
"talking science." Notice the tutor even starts giving positive
feedback for answers that are wrong. However, this is a nice
trait not many students display - a willingness to volunteer wrong
ideas. The misconception displayed in line 646 is astounding -
the student thinks just because a statement is an initialization that
it will only execute one time, even
if it is placed inside the loop body. The tutor spends
quite a bit of time explaining why this is not the case, resorting even
to a simulated execution of the code.
Further Reading and Feedback
Please see the
CPP
homepage for further information. A link to the SIGCSE 03
paper is there (as well as on the ACM portal), and some screenshots of
the system (which may help to visualize what is going on in the
dialogues).
Also, this work is the basis for my dissertation, so if you have any
comments, questions, feedback, or suggestions, please send them to me
(email =
hcl <AT> cs.pitt.edu)
at any time. I'm interested not only in analysis, but opinions on
if you think this is effective (it appears to be for my students), and
maybe other tutoring strategies you may think would be effective.
Last updated: Tue
Jul 1 17:47:50 EDT 2003