Computational thinking has become the calling card for re-introducing coding into schools. While much attention has focused on how students engage in designing systems, applications, and other computational artifacts as a measure of success for computational thinking, far fewer efforts have focused on what goes into remediating problems in designing systems and interactions because learners invariably make mistakes that need fixing-or debugging. In this panel, we examine the often overlooked practice of debugging that presents significant learning challenges (and opportunities) to students in completing assignments and instructional challenges to teachers in helping students to succeed in their classrooms. The panel participants will review what we know and don't know about debugging, discuss ways to conceptualize and study debugging, and present instructional approaches for helping teachers and students to engage productively in debugging situations.

This study examines the extent to which novice computing students with minimal computer science coursework and no training in user interface (UI) evaluation consider UI concepts such as usability, user experience, and the context in which software will be used when evaluating an interface. In analyzing the responses of 149 novice computer science students who were asked to evaluate two interfaces for converting temperatures between Fahrenheit and Celsius, we observed that students generally considered usability and user experience factors, but were less likely to consider context. For educators, this exact task could be given to a class in order to initiate discussion of user-centered design; the study also provides a framework for structuring the discussion. More generally, the results of this study provide insight into some opportunities and challenges in teaching good interface design and evaluation skills.

This paper investigates what students understand about algorithm efficiency before receiving any formal instruction on the topic. We gave students a challenging search problem and two solutions, then asked them to identify the more efficient solution and to justify their choice. Many students did not use the standard worst-case analysis of algorithms; rather they chose other metrics, including average-case, better for more cases, better in all cases, one algorithm being more correct, and better for real-world scenarios. Students were much more likely to choose the correct algorithm when they were asked to trace the algorithms on specific examples; this was true even if they traced the algorithms incorrectly.

A qualitative analysis of debugging strategies of novice Java programmers is presented. The study involved 21 CS2 students from seven universities in the U.S. and U.K. Subjects "warmed up" by coding a solution to a typical introductory problem. This was followed by an exercise debugging a syntactically correct version with logic errors. Many novices found and fixed bugs using strategies such as tracing, commenting out code, diagnostic print statements and methodical testing. Some competently used online resources and debuggers. Students also used pattern matching to detect errors in code that "just didn't look right". However, some used few strategies, applied them ineffectively, or engaged in other unproductive behaviors. This led to poor performance, frustration for some, and occasionally the introduction of new bugs. Pedagogical implications and suggestions for future research are discussed.

As the third in a series of projects investigating commonsense computing -- the relevant knowledge that students have before any formal study of computing -- we examine students' commonsense understanding of concurrency. Specifically, we replicated (with modifications) an experiment by Ben-David Kolikant. [2] Ben-David Kolikant's data were gathered from high-school seniors who had previously studied computing, at the beginning of an advanced class in concurrent and distributed programming. Modifying one of her questions to reflect our students' lack of background, we asked students at five different institutions, in the first week of CS1, to describe in English the problems that might arise when more than one person is selling seats to a concert.Almost all students (97%) identified the problem of interest -- that a race condition may occur between sellers. 73% of students identified at least one possible solution. We found that the categorizations developed by Ben-David Kolikant were also meaningful when applied to our data, that our beginning CS1 students are more likely to give centralized solutions (as opposed to decentralized ones) than Ben-David Kolikant's concurrency students, and that the granularity of solutions is finer among the more experienced students.

We examine students' commonsense understanding of computer science concepts before they receive any formal instruction in the field. For this study, we asked students on the first day of a CS1 class to describe in English how they would arrange a set of numbers in ascending, sorted order; we then repeated the experiment asking students to sort a list of dates (in mm/dd/yyyy format).We found that a majority of students described a coherent algorithm; some described versions of insertion or selection sort, but many gave unexpected algorithms. We also found significant differences between responses given for sorting numbers versus dates. Based on our analysis of the data we suggest that beginning-programming instructors more explicitly discuss data types, begin loop instruction with post-test loops, assist students in recognizing implicit conditional and iteration use in natural language solutions to probls, and recognize that novices and experts focus on different aspects of the probl in even basic probl solving tasks.

We examine students' commonsense understanding of computer science concepts before they receive any formal instruction in the field. Specifically, we asked students on the first day of a CS1 class to describe in English how they would arrange a set of numbers in ascending, sorted order. We repeated the experiment with students in an introductory economics course, and again with a sub-population of the CS1 students after ten weeks of Java instruction.We found that a majority of beginning computing students could describe a coherent algorithm to correctly sort a list of numbers, while less than a third of general college students could do so. Many students gave versions of selection or insertion sort, but the most common algorithm treated numbers as strings and manipulated them digit by digit. Students who used iteration strongly preferred post-test loops. Finally, some aspects of student performance became worse after ten weeks of CS1 instruction.

We are studying what students know about computer science-related topics before they take formal coursework at the university level. Preliminary results suggest that entering students have a fairly sophisticated understanding of algorithms. We are exploring other central computing topics for similar shared commonsense understanding.

No abstract available.

Novice programmer knowledge contains a mixture of well-formed, in-transition and muddled conceptual structures. In this paper we describe an analysis of the in-transition and muddled items that are not fully integrated into the novices' cognitive structures. When participants were asked to perform card sorts of programming concepts into categories, 23% of their categories were "ragbags": categories with names such as "don't know," "not sure," or "not applicable"'' that indicate that the students have little or no knowledge of the concepts placed in those categories.In this study, we find that there are distinct differences in the uses of the ragbags. In particular, we find that terms considered more abstract tend to be placed into Don't Know and Not Sure ragbags more often than concrete terms; and students categorized as low performers tend to use Not Sure far more often than high performers but Don't Know and Not Applicable less often. We also find evidence that the meaningfulness of a concept is likely to be related to the vocabulary used in the classroom, suggesting that students may assimilate abstract concepts into their conceptual structures more quickly if one uses the terms more frequently.

In this paper, we describe activities undertaken at our university to revise our computer science program to develop an environment and curriculum which encourages creative, hands-on learning by our students. Our main changes were the development of laboratory space, increased hands-on problem solving activities in the introductory course, open-ended programming projects in the early courses including a requirement of an open-ended project extension for an A grade, and the integration of a seminar into the senior project requirement. Our results suggest that these changes have improved student skill and willingness to deal with new problems and technologies. An additional surprising side-effect appears to be a dramatic increase in retention over the first two years, despite lower overall grade averages in those courses.

Abstract: This paper presents a case study of the use of a repeated single-criterion card sort with an unusually large, diverse participant group. The study, whose goal was to elicit novice programmers' knowledge of programming concepts, involved over 20 researchers from four continents and 276 participants drawn from 20 different institutions. In this paper we present the design of the study and the unexpected result that there were few discernible systematic differences in the population. The study was one of the activities of the National Science Foundation funded Bootstrapping Research in Computer Science Education project (2003).

The focus of this panel is the role of computer science faculty in the undergraduate research process. The panel participants will share their personal experiences to highlight different approaches in developing and encouraging undergraduate computer science research.

In this paper, we describe the formatting guidelines for ACM SIG Proceedings.

No abstract available.

Our breadth-first introduction to Computer Science presents the fundamentals of the discipline by engaging students in active learning. In designing and teaching this course we established four goals. First, since problem solving is essential to Computer Science, students should learn to solve problems proficiently in several areas. Second, since Computer Science is best learned through intimate engagement with the material, students should learn in an active classroom environment. Third, students of all experience levels and majors should feel equally comfortable with the course material. And fourth, students should discover that Computer Science is interesting, relevant and fun.We encountered two major obstacles to achieving our goals. First, in an introductory course such as this, one regularly finds a range of experience among students: some have never used a computer, others have used it only for word processing, and still others have built their own computers. Therefore, designing an interesting and useful course that doesn't bore or intimidate any students is a significant challenge. Second, students have a wide variety of preferred learning styles which affect the way they gather and process information. Instructors also have a preferred learning style which affects the way they present the course material. Therefore, presenting the material in ways that engage all learning styles is another challenge.Despite these obstacles, our presentation strategies for this course have yielded promising results. After teaching the course for three semesters, we have observed the following. First, the course involves every student and is highly interactive. Second, as students learn the core material they ask more depth questions and achieve a higher overall level of knowledge than students in previous semesters of the course. Finally, students enjoy the class and report that they are highly satisfied with their learning; more CS I students are choosing to take additional Computer Science classes.

We examine a very simple asynchronous model of parallel computation that assumes the time to compute a task is random, following some probability distribution. The goal of this model is to capture the effects of unpredictable delays on processors, due to communication delays or cache misses, for example. Using techniques from queueing theory and occupancy problems, we use this model to analyze two parallel dynamic programming algorithms. We show that this model is simple to analyze and correctly predicts which algorithm will perform better in practice. The algorithms we consider are a pipeline algorithm, where each processor i computes in order the entries of rows i, i+p, and so on, where p is the number of processors; and a diagonal algorithm, where entries along each diagonal extending from the left to the top of the table are computed in turn. It is likely that the techniques used here can be useful in the analysis of other algorithms that use barriers or pipelining techniques.

We examine a very simple asynchronous model of parallel computation that assumes the time to compute a task is random, following some probability distribution. The goal of this model is to capture the effects of unexpected delays on processors.