Monthly Archives: August 2011

Debugging: Meta-cognition and explicit teaching of strategies

The 2007 SIGCSE paper “Debugging: The Good, the Bad, and the Quirky – a Qualitative Analysis of Novices’ Strategies” by Murphy, Lewandowski, McCauley, Simen, Thomas and Zander lists debugging strategies and reports a study of 21 students to observe and categorize their debugging behavior.  To quote from the authors’ conclusion:

Many unproductive activities appeared to stem from insufficient meta-cognition. Some students did not recognize when they were stuck, thus they did not know to try a different approach. Those who stubbornly traced in their heads often did not realize they were suffering from cognitive overload and might be more productive if they tracked on paper or via print statements. Others were blind to alternative bug sources. Debugging instruction should incorporate these meta-cognitive factors, perhaps taking the form of self-questions: “What else could I try?’, “Is this too much to keep track of in my head?”, and “What are other possible sources of the bug?”

Explicit teaching of processes for students to reflect on their own learning and disciplinary experiences is suggested, as it is from a lot of other research literature. We add here that we should experiment with exposing students to research literature itself such as the above cited paper.

  • Students will relate to experiences of people just like themselves in current and immediately anticipated situations.  The students in the study were taking a CS2 course.
  • Particular components of debugging, as itself a component of programming, are identified:

    “Debugging is difficult for novice programmers. Similar to new drivers who must learn to steer, accelerate, brake, etc. all at once, novice debuggers must apply many new skills simultaneously. They must understand the operation of the intended program and the execution of the actual (buggy) program; have general programming expertise and an understanding of the programming  language; comprehend the application domain; and have knowledge of bugs and debugging methods [2]. Unfortunately, most novices’ knowledge of these skills is fragile at best [12], causing many to find debugging difficult and frustrating.”

  • Particular practices and tools are introduced: “Gain domain knowledge, Isolating the problem. Tracing, including: Mental, Print & Debugger, Pattern matching, Consider alternatives, Testing, Environmental, Understanding code, Work around problem, Using resources, Just in Case, Using Tools, Tinkering”
  • More importantly, results and examples of critical evaluation are demonstrated.
  • Such material will foster respect and interest in attitudes and interests of academic research.

Learning GIT

Spent a few days learning GIT.

Some links I found:

  1. The GIT user manual from  I cloned the git repository for git itself.  Like the description: “Information Manager from Hell”!
  2. The GIT Parable Starts with a good promise, lets see..  It is really clear and easy to read, although I already understood much of it from other sources.  It ends with3 links to good-looking websites with more detail.
  3. Computer scientist’s intro
  4. (update from csi500 web site’s list).

GIT is based on objects located by references. The references are visible as the hashes.

Key concepts: Working tree. Index. Commits. HEAD pointer.

Concepts: Branch (for clarity, named variable pointer to a commit rather than a line of deveopment).

Computer Science Education Journals


Transactions on Computing Education, formerly Journal on Educational Resources in Computing

Computer Science Education

Abstractions feel concrete

Things that people say are abstract such as mathematics feel to me, having training and inclinations towards that subject, very concrete, particular and real.  They are not things for which the rules and nature are not clearly understandable, like justice and freedom. Perhaps the ability to deal with abstract things is the ability to think about them in the same way as concrete things.  Of course, this way of dealing with things may be much more successful in areas such as programming and mathematics than it is in areas like ethics and esthetics.

The following paper probes the trouble with seeking correlations between programming ability and “abstraction” ability. It classifies various meanings of abstraction and reports research into correlating measurements of kinds of abstraction ability with performance in computer science courses: “Abstraction Ability as an Indicator of Success for Learning Computing Science?” by  Bennedsen and Caspersen in ICER’08, September 6–7, 2008, Sydney, Australia(–icer2008.pdf )


Shortcomings of Alice, Scratch, Myro, etc.

Having taught a few CS0 courses, I got the impression that programming learning environments including those above enable beginners to do easy attractive and satisfying things, but do not automatically (at least) lead them to do the harder things.  I was particularly disappointed that the old version of Alice did not provide easy to use arrays that could be employed in teaching basic search and sorting algorithms.

Misconceptions and Teaching Them

Collecting and Categorizing Misconceptions

What to pay attention to.

I read the paper Habits of Programming in Scratch by Orni Meerbaum-Salant mentioned in Mark Guzdial’s excellent Computing Education Blog.  It is not at all surprising after trying Scratch.

Guzdial has an interesting earlier blog entry My Students Know Far Less Than I Ever Expected about being surprised at students beginning data structures knowing far less than he expected.  The misconception is basically about the practice of detailed analysis of questions and problems that CS courses are expected to teach.  Respondents remark that the subject was a “trick question” that even some of them got wrong when they first saw it.  It also suggests misconceptions about the meanings of code.

Here is a copy of a reply I added:

Having taught data structures many times, I am not at all surprised by the outcome of the problem, even after the class discussion.

The main misconception that the students have is about what they must pay attention to when they face examples of programs and questions about them in order effectively learn elements of the discipline.  They must often attend to the same things of course when they write or debug their own or other peoples’ code. Even the professionals, who rightly observed that the problem is a “trick question”, fell for the trick, I guess, because they did not realize that they needed to turn on the mode of detailed code and question analysis rather than recognize a familiar pattern.

How can we teach “what it is you must pay attention to”, teach the habit to pay attention to that when it is appropriate, and teach how to recognize the situations where particular things to pay attention to are appropriate?

Should we tell the students that certain in-class questions are the kinds of questions that they must ask themselves while they are engaging in disciplinary work, necessary for that work to be effective?

Research on Misconceptions.

Yesterday, I found some research particularly germane to classifying and addressing misconceptions in elementary programming:

UUhistle: misconceptions about variables surveyed and addressed.

UUhistle, A Program Visualization Tool for Introductory Programming Education distributes a Java applet that animates at a fine grain level a simple model for Python execution that includes the creation and assignments to variables.  It is backed up by research: The project is part of Juha Sorva‘s doctoral dissertation.

From the same academic program, the master’s dissertation of Juha Helminen addresses both the issues of problem solving skills and of misconceptions.  Here’s a page of many links to its publications.

Sorva’s paper “The Same But Different Students’ Understandings of Primitive and Object Variables” in SIGCSE’08, March 12–15, 2008, Portland, Oregon, USA describes different ways of understanding primitive and object variables associated with the corresponding misunderstandings.  From the abstract: “The results show that learners create various kinds of mental models of programming concepts, and that the concept of variable, which is fundamental to most types of programming, is understood in various non-viable ways.”  The author cites two ideas from education theories: First, “constructivist” theory holds that student form and modify mental models, and  “Phenomenography” described by Sorva as an “approach to research that investigates phenomena and people’s relationships to those phenomena”.  Further:

In a research project of this kind, interviews are used as a data collection method. Data collection is followed by or intertwines with qualitative data analysis. During analysis, the researcher, in dialogue with the data, delimits the phenomenon of interest. Different ways of understanding or experiencing the phenomenon are enumerated as an outcome space consisting of a (smallish) number of categories of description. Outcome spaces often take the form of a hierarchy or tree of categories related to each other. The intention in phenomenographic research is not to point out which specific kinds of understanding each individual has, but to identify different ways in which a phenomenon can be understood, or experienced, on a collective level.

And, in contrast to other research (which excludes incorrect understandings from the “outcome space” used by the experimenter to classify response.) he cites, “both correct understandings (as deemed by the researcher) and partially incorrect understandings are included in the outcome space. Partially incorrect understandings are understandings that extend correct understandings in incorrect ways. ”

Cognitive conflict, variable and reference assignment, approach combining constructive and visualization supported teaching.

“Using Cognitive Conflict and Visualisation to Improve Mental Models Held by Novice Programmers” by Linxiao Ma, John Ferguson, Marc Roper, Isla Ross and Murray Wood in SIGCSE’08, March 12–15, 2008, Portland, Oregon, USA.

More recent publication: “Investigating and Improving the Models of Programming Concepts Held by Novice Programmers.” L. Ma, J. Ferguson, M. Roper, and M. Wood. Computer Science Education. 21 (1). March 2011. pp. 57-80

The Two Humps and a test alleged to predict programming ability from consistency of ones assumptions.

Dehnadi, S., and Bornat, R. 2006. The camel has two humps.
Middlesex University Working Paper.

This research was said to attract some attention a few years ago.  It was a major citation in the Ma et. al.  paper.  However, the authors unsuccessfully attempted to reproduce the main results and reported this in Another such failure was reported in–iticse2007.pdf and

Research about the tight connectedness among the critical concepts in programming

I am extremely impressed by the recent paper by Anthony Robbins: “Learning edge momentum: A new account of outcomes in CS1” He proposes that the bimodal grade distributions in beginning programming courses is the result (in my words) of the central limit theorem failing to apply to such grades because those grades are sums on non-independent random variables. He calls this the “momentum effect.” The paper surveys and criticizes the many proposed reasons for the bimodal phenomenon. Robbins’ formulates and simulates a probabilistic model for concepts learned sequentially and where the effective learning of each depends on effective learning of the previous.  I conjecture that the effect of dependence among the scores does not require the this sequentiality and more flexible models of dependencies may be theoretically interesting.

Some critical responses:  Lister’s column in Sept. 2010 Inroads I do what Lister criticizes by giving partial exam credit on programming problems for each statement or operation the student writes that should appear in a correct solution.  I do this because if I did not do it, the scores would be extremely bimodal. I wonder if bi-modality is not apparent simply because the exams do not test the full measure of what giving a correct solution to a programming problem means! Ultimately, I agree with Lister in that better validated assessments in programming courses are needed if hypotheses like those of Robbins are to be scientifically tested.

Here is another:  is a paper by Petersen, Craig and Zingaro in the 2011 SIGCSE. The point seems to be summarized by their saying: “In Robins’ model, a misunderstanding of conditionals may result in a decreased probability of understanding loops. Instead, we argue that her misunderstanding of conditionals decreases the probability that she can demonstrate understanding of loops.”  In my view, understanding of loops necessarily includes the ability to demonstrate that whatever is coded in the loop body or in the continuation condition is repeatedly executed.

My blog page on archival journal in computing education.