This study focuses on CS minor students' decisions to drop out from the CS1 course. The high level of drop out percentage has been a problem at Helsinki University of Technology for many years. This course has yearly enrolment of 500-600 students and the drop out percentage has varied from 30-50 percents.Since we did not have clear picture of drop out reasons we conducted a qualitative interview research in which 18 dropouts from the CS1 course were interviewed. The reasons of drop out were categorized and, in addition, each case was investigated individually. This procedure enabled us to both list the reasons and to reveal the cumulative nature of drop out reasons.The results indicate that several reasons affect students' decision to quit the CS1 course. The most frequent reasons were the lack of time and the lack of motivation. However, both of these reasons were in turn affected by factors, such as the perceived difficulty of the course, general difficulties with time managing and planning studies, or the decision to prefer something else. Furthermore, low comfort level and plagiarism played a role in drop out. In addition, drop out reasons cumulated.This study shows that the complexity and large variety of factors involved in students' decision to drop the course. This indicates that simple actions to improve teaching or organization on a CS1 course to reduce drop out may be ineffective. Efficient intervention to the problem apparently requires a combination of many different actions that take into consideration the versatile nature of reasons involved in drop out.

/pdf/why-students-drop-out-cs1-course-1pjayty9k5.pdf

Why students drop out CS1 course

This article is a survey of program visualization systems intended for teaching beginners about the runtime behavior of computer programs. Our focus is on generic systems that are capable of illustrating many kinds of programs and behaviors. We inclusively describe such systems from the last three decades and review findings from their empirical evaluations. A comparable review on the topic does not previously exist; ours is intended to serve as a reference for the creators, evaluators, and users of educational program visualization systems. Moreover, we revisit the issue of learner engagement which has been identified as a potentially key factor in the success of educational software visualization and summarize what little is known about engagement in the context of the generic program visualization systems for beginners that we have reviewed; a proposed refinement of the frameworks previously used by computing education researchers to rank types of learner engagement is a side product of this effort. Overall, our review illustrates that program visualization systems for beginners are often short-lived research prototypes that support the user-controlled viewing of program animations; a recent trend is to support more engaging modes of user interaction. The results of evaluations largely support the use of program visualization in introductory programming education, but research to date is insufficient for drawing more nuanced conclusions with respect to learner engagement. On the basis of our review, we identify interesting questions to answer for future research in relation to themes such as engagement, the authenticity of learning tasks, cognitive load, and the integration of program visualization into introductory programming pedagogy.

A Review of Generic Program Visualization Systems for Introductory Programming Education

As computing becomes a mainstream discipline embedded in the school curriculum and acts as an enabler for an increasing range of academic disciplines in higher education, the literature on introductory programming is growing. Although there have been several reviews that focus on specific aspects of introductory programming, there has been no broad overview of the literature exploring recent trends across the breadth of introductory programming. This paper is the report of an ITiCSE working group that conducted a systematic review in order to gain an overview of the introductory programming literature. Partitioning the literature into papers addressing the student, teaching, the curriculum, and assessment, we explore trends, highlight advances in knowledge over the past 15 years, and indicate possible directions for future research.

/pdf/introductory-programming-a-systematic-literature-review-3yllvt7k18.pdf

Introductory programming: a systematic literature review

This paper reports on the authors use of the SOLO taxonomy to describe differences in the way students and educators solve small code reading exercises. SOLO is a general educational taxonomy, and has not previously been applied to the study of how novice programmers manifest their understanding of code. Data was collected in the form of written and think-aloud responses from students (novices) and educators (experts), using exam questions. During analysis, the responses were mapped to the different levels of the SOLO taxonomy. From think-aloud responses, the authors found that educators tended to manifest a SOLO relational response on small reading problems, whereas students tended to manifest a multistructural response. These results are consistent with the literature on the psychology of programming, but the work in this paper extends on these findings by analyzing the design of exam questions.

/pdf/not-seeing-the-forest-for-the-trees-novice-programmers-and-sg5i9i8a1s.pdf

Not seeing the forest for the trees: novice programmers and the SOLO taxonomy

Our research explores what we call compilation behaviour: the programming behaviour a student engages in while repeatedly editing and compiling their programs. This edit-compile cycle often represents students' attempts to make their programs syntactically, as opposed to semantically, correct. Over the course of two years, we have observed first-year university students learning to program in Java, collecting and studying thousands of snapshots of their programs from one compilation to the next. At the University of Kent, students are introduced to programming in an objects-first style using BlueJ, an environment intended for use by novice programmers.

Methods and tools for exploring novice compilation behaviour

A study by a ITiCSE 2001 working group ("the McCracken Group") established that many students do not know how to program at the conclusion of their introductory courses. A popular explanation for this incapacity is that the students lack the ability to problem-solve. That is, they lack the ability to take a problem description, decompose it into sub-problems and implement them, then assemble the pieces into a complete solution. An alternative explanation is that many students have a fragile grasp of both basic programming principles and the ability to systematically carry out routine programming tasks, such as tracing (or "desk checking") through code. This ITiCSE 2004 working group studied the alternative explanation, by testing students from seven countries, in two ways. First, students were tested on their ability to predict the outcome of executing a short piece of code. Second, students were tested on their ability, when given the desired function of short piece of near-complete code, to select the correct completion of the code from a small set of possibilities. Many students were weak at these tasks, especially the latter task, suggesting that such students have a fragile grasp of skills that are a prerequisite for problem-solving.

/pdf/a-multi-national-study-of-reading-and-tracing-skills-in-543cusr6jw.pdf

A multi-national study of reading and tracing skills in novice programmers

Factory: A Creational Pattern Another obvious requirement for music-notation software is the ability to insert notation into an existing score. A typical example is inserting a note into the score. The need to insert a note is present in several places in the OMIS software: the editor must be able to do so, and so must the part of OMIS that interprets the textual output from the scanning phase. As software designers, we want to encapsulate this note-creation process into one method. The underlying code must do something along like the following: void insertNote(Staff *staff, int atStaffDegree) { Note *newNote = new Note(); staff->insertNote(newNote, atStaffDegree);

A Tutorial on Design Patterns for Music Notation Software

Ninth Workshop on Pedagogies and Tools for the Teaching and Learning of Object Oriented Concepts

This paper describes a on-going empirical study, inspired by phenomenography, aiming at understanding how students from the humanities learn the concepts of objects and object-orientation during a programming course.

Morten Lindholm

Papers

A multi-national study of reading and tracing skills in novice programmers

A Tutorial on Design Patterns for Music Notation Software

Ninth Workshop on Pedagogies and Tools for the Teaching and Learning of Object Oriented Concepts

Development of object-understanding among students in the humanities