Student `copying' is often considered negatively as thoughts of plagiarism come to mind. Previously, we investigated the ways that instructors expect to use copying and imitation positively in their teaching. In this paper, we follow up that study by focusing on the student perspective and explore the ways in which students see copying and imitating as positive tools in learning to program (both at an introductory level and through more advanced learning of algorithms, etc.). In a qualitative research study, using semi-structured interviews, students were asked about how they use copying positively - their goals when they copy, how they go about it, how they view the experience of copying, and results beyond simply fulfilling their immediate goals. When comparing student results with the previous study, it was noted that there is some level of agreement between instructors and students about how copying can be useful for learning to program. There is also some degree of mismatch between instructor and student views. Students did not report imitating instructors' approaches to learning and sometimes were unsure about whether they were supposed to copy the materials that they were given. This leads to some teaching suggestions in terms of instructors being more explicit in their attitude to this type of `legitimate' copying and imitation.

Students' "copying" is often considered negatively. In this paper, we explore the ways in which copying and imitation are used positively by computing instructors in their teaching. We found that instructors expect their students to use these strategies in many different contexts and at many different levels.

We replicate a study and extend previous research that examined graduating students' achievement and understanding when asked to "produce a design". In this paper, we examine software designs produced by students at an earlier stage in their undergraduate studies -- the midpoint. We were looking for characteristics of the development of skill at software design as students progress through the curriculum. These students did about as well as graduating students from the same institution in terms of the quality of their software designs, although they failed to produce as many complete designs. In addition to attributes uncovered in previous research, a new design attribute was noticed -- meaningful links between static components. We raise the question of where GUI designs fit in the area of software design.

In this article, we address the question of why computing students choose to learn computing topics on their own. A better understanding of why some students choose to learn on their own may help us to motivate other students to develop this important skill. In addition, it may help in curriculum design; if we need to leave some topics out of our expanding curriculum, a good choice might be those topics that students readily learn on their own. Based on a thematic analysis of 17 semistructured interviews, we found that computing students’ motivations for self-directed learning fall into four general themes: projects, social and peer interactions, joy of learning, and fear. Under these, we describe several more specific subthemes, illustrated in the words of the students. The project-related and social motivations are quite prominent. Although these motivations appear in the literature, they received greater emphasis from our interviewees. Perhaps most characteristic of computing is the motivation to learn to complete some project, both projects done for fun and projects required for school or work.

We expand upon previous research that looked at the question: "Can graduating students design software systems?" Specifically we want to examine students' understanding of the phenomenon "produce a design." What does this instruction mean to them? In order to investigate student understandings, we examined their designs using a phenomenographic approach.

Threshold concepts can be used to both organize disciplinary knowledge and explain why students have difficulties at certain points in the curriculum. Threshold concepts transform a student's view of the discipline; before being learned, they can block a student's progress.

Research has shown that most learning in the workplace takes place outside of formal training and, given the swiftly changing nature of the field, computer science graduates more than most workers, need to be able to learn computing topics outside of organized classes.

In this paper we revisit previous research to elaborate on the question: "Can graduating students design software systems?" The work concluded that the answer was "not really". We wished to determine if this was true currently at our institution and also to look at whether students were able to design software in groups, and evaluate others' designs. In summary, it appears that our students, just as in the original experiment, struggle with doing design, even in a group situation. The representation of behavioral design was particularly lacking. That said, students were able to recognize weaknesses when evaluating other group designs. Based on our findings, we provide several pedagogic recommendations.

Transformational biographies are used to shed light on situations when students have experienced 'surprise.' These biographies are examined in light of a philosophical position that surprise is useful in engendering learning, and, that as educators, we should try and set up situations in which our students experience it more often. The paper reports on a grounded-theory inspired examination of 108 students' transformational biographies for evidence of surprise. Students clearly perceived an 'anomaly or contradiction to a previous belief or understanding' in just under half of them. The paper then goes on to further identify different kinds of surprise and the triggers that caused them and concludes with suggestions for enhancing learning by capitalizing on students' surprise.

We examine the changes in the ways computing students view their field as they learn, as reported by the students themselves in short written biographies. In many ways, these changes result in students thinking and acting more like computer scientists and identifying more with the computing community. Most of the changes are associated with programming and software engineering, rather than theoretical computer science, however.

We examine the transformations experienced by students during their study of computing. These transformations led to changes in the students' perceptions of computer science, in their sense of identity as computer scientists, their behavior and their confidence. The changes are caused by learning or using particular concepts, and often associated with writing computer programs, learning new programming languages, or interacting with peers.

We present what students say about their preferred learning style to succeed in introductory programming. Using the Felder-Silverman learning styles, students contrasted the 'best' learning style for programming with the 'best' for learning mathematics. Overall students believe that while they learn mathematics using a reflective style, learning to program is significantly more active. They also believe learning mathematics has a strong verbal component, whereas learning programming is primarily visual.

This paper examines transformational learning experiences of computing students as a way to better understand threshold concepts in computing. From empirical evidence we found that students often describe transformative experiences as learning situations in which they were led to use various kinds of abstraction, for example modularity, data abstraction, inheritance, polymorphism, reuse, design patterns, and complexity. Some students describe an abstract concept as coming first, and then needing to be made concrete though application; others describe transformations in which they learn the advantages of these abstract concepts from their experience of not using them.

Data sharing is common, and sometimes even required, in other disciplines. Creating a mechanism for data sharing in computer science education research will benefit both individual researchers and the community. While it is easy to say that data sharing is desirable, it is much more difficult to make it a practical reality.

Jane sees 50 compiler errors as a challenge. John sees them as defeat. Psychology research suggests these contrasting reactions may stem from students' self-theories, or their beliefs about themselves. Jane's reaction is characteristic of a growth mindset, the idea that with hard work and persistence, one's intelligence can increase. John's behavior is in line with a fixed mindset, the belief that individuals are born with a certain amount of intelligence and there is little they can do to change it. Numerous studies of self-theories have shown that students with a growth mindset perform better in academic settings; they cope more effectively with challenges, maintain higher grades, and are less susceptible to stereotype threat. In this study we attempted a "saying is believing" intervention to encourage CS1 students to adopt a growth mindset both in general and towards programming. Despite notable success of this type of intervention in a non-CS context, our results offered few statistically significant differences both from pre-survey to post-survey and between control and intervention groups. Further, the statistically significant results we did find differed in direction between institutions (some students exhibited more growth response, others less). We analyzed further evidence to explore possible confounding issues including whether our intervention even registered with students and how students interpreted the questions which we used to assess their self-theories.

Psychology studies have shown that students' beliefs about their own intelligence--whether they view intelligence as fixed or malleable-have an important influence on student development and achievement. Yet the impact of these theories on success in Computer Science (CS) has not been directly investigated. Self-theories research has shown that students with a fixed mindset are more likely to exhibit a helpless response to substantial challenges and to experience decreases in self-esteem during college. Those with a growth mindset welcome challenges, displaying a mastery-oriented response, and maintaining self-esteem, primarily because they attribute failure to a lack of effort rather than a lack of intellectual ability. This paper introduces self-theories research, and relates this research to several issues in CS Education. We then make suggestions for how CS educators can consider self-theories in their teaching and research.

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.

In this paper, we present the results of an experiment in which we sought to elicit students' understanding of object-oriented (OO) concepts using concept maps. Our analysis confirmed earlier research indicating that students do not have a firm grasp on the distinction between "class" and "instance." Unlike earlier research, we found that our students generally connect classes with both data and behavior. Students rarely included any mention of the hardware/software context of programs, their users, or their real-world domains. Students do mention inheritance, but not encapsulation or abstraction. And the picture they draw of OO is a static one: we found nothing that could be construed as referring to interaction among objects in a program. We then discuss the implications for teaching introductory OO programming.

This paper is part of an ongoing series of projects in which we are investigating "threshold concepts": concepts that, among other things, transforms the way a student looks as the discipline and are often troublesome to learn. The word "threshold" might imply that students cross the threshold in a single "aha" moment, but often they seem to take longer. Meyer and Land introduce the term "liminal space" for the transitional period between beginning to learn a concept and fully mastering it.

In this paper we present a phenomenographic analysis of computer science instructors' perceptions of student success. The factors instructors believe influence student success fell into five categories which were related to: 1) the subject being taught, 2) intrinsic characteristics of the student, 3) student background, 4) student attitudes and behaviour and 5) instructor influence on student development. These categories provide insights not only into how instructors perceive students, but also how they perceive their own roles in the learning process. We found significant overlap between these qualitative results, obtained through analysis of semi-structured interviews, and the vast body of quantitative research on factors predicting student success. Studying faculty rather than students provides an alternative way to examine these questions, and using qualitative methods may provide a richer understanding of student success factors.

In this paper, we begin by considering object-oriented programming concepts and typical novice misconceptions as identified in the literature. We then present the results of a close examination of student programs, in an objects-first CS1 course, in which we find concrete evidence of students learning these concepts while also displaying some of these misconceptions. This leads to the development of two checklists that educators can use when designing or grading student programs.

We report on a study of novice programmers' object oriented class designs. These designs were analysed to discover what faults they displayed. The two most common faults related to non-referenced classes (inability to integrate them into the solution), and problems with attributes and class cohesion. The paper ends with some implication for teaching that may be indicated by the empirical results.

How do beginning students approach problems which require them to read and understand code? We report on a Grounded Theory-based analysis of student transcripts from 12 institutions where students were asked to "think aloud" when solving such problems. We identify 19 strategies used by students. Primary results are that all students employ a range of strategies, there were (in total) many different strategies that were applied, students use multiple strategies on each individual problem, students applied different strategies to different types of questions, and students often applied strategies poorly. We show that strategies conform with existing education theories including Bloom's Taxonomy and the Approaches to Study Inventory. Additionally, we discuss emergent theories developed through a card sort process.

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).

This paper reports on an experiment in which first year programming students were given explicit encouragement to use Object (Instance) diagrams when tracing code in multiple-choice questions. We conjectured that by providing scaffolding in this technique, students would be helped to understand the code better and that they would then continue to draw their own diagrams in similar situations. This turned out not to be the case. Although generally students who draw diagrams do better in questions that test their understanding of code behaviour and object referencing, our intervention does not appear to have helped students and the students who were exposed to the intervention were not more likely to go on to use the technique themselves.

This paper describes a project being undertaken at the University of Wales, Aberystwyth that captures students' designs in an attempt to improve the pedagogy. To enhance their understanding of object oriented programming, students are given an environment that enables distance working and encourages group collaboration whilst capturing all aspects of development of their designs. To enhance the teaching of programming and software design, instructors are given access to complete design histories enabling them to better understand how the students view their design processes, the problems that arise and the steps that they take to resolve them.

This paper reports on how first-year students who have programmed before see their programming interest and ability and how this self-perception relates to their performance in the introductory programming course. In particular we examine how this self-perception is reflected in their reactions to the pair-programming technique for developing software.Students who had programming experience before University were given a survey that placed them on a scale that we have called Code Warrior to Code-a-phobe. We then placed them in 'opposite' and 'similar' pairs for a pair programming exercise and surveyed their reactions. There was evidence that students who have considerable self-confidence do not enjoy the experience of pair programming as much as other students and that students produce their best work when placed in pairs with students of similar self-confidence levels.

In 1993, the first year class in the Department of Computer Science at the University of Wales, Aberystwyth totalled just 93 students. This year it is 190. In line with most universities in the UK the total number of students in the department has more than doubled in the last five years and as is typical, the number of staff is largely unchanged. This paper describes two main development phases that have been undertaken to enhance the student experience and improve the quality of our teaching despite the ever-increasing workload.

Summary form only given, as follows. We envisage this workshop as a chance for Software Engineering Educators to share their challenges, successes and failures in teaching Software Engineering concepts to First Year (or beginning) students The specifics of the workshop will depend to some extent on the interests of the participants, but as a basis for organisation and discussion we will ask all participants to fill in a questionnaire to be provided in the conference registration kits. We will begin the workshop by sharing the basic results of the questionnaires and then ask participants to share their biggest challenges in teaching Software Engineering to beginners, what they have done that has been successful (and any things they have tried that didn't work), what students have trouble understanding, what topics may not even fit in an introductory course, etc. We will then break the group up into interest groups on particular topics (eg. reuse, programming, professionalism, design, testing, etc.) and those groups will brainstorm about one particular issue. The workshop will end with the groups sharing ideas. Our hope is that this workshop will not only be useful in and of itself but will also provide a springboard for participants to find colleagues with similar interests and enthusiasms.

This paper reports on the implication of different preferred learning styles on students' performance in the introductory programming sequence and on work in progress on how to accommodate these different styles.Students were given a learning styles preference test and then their preferred learning styles were compared to their performance on the exam and the practical programming part of the introductory programming module. There were significant differences in performance between groups of students.This result could lead one to two possible conclusions. One might be that some students' learning styles are more suited to learning programming than others.An alternative explanation is that our current methods of teaching advantage students with certain learning preference styles. We are at present in the process of testing this second assumption by providing students with a wider range of learning materials. We will then see if student performance is improved by using our current results as a baseline for comparison

The paper reports on ongoing work in the Department of Computer Science at the University of Wales. It describes a learning environment (Software Engineering Teaching and Learning System, SETLAS), that has been successfully used with first year software engineering students and that is the result of a synergy between several groups within the department. The resulting system has exceeded the objectives for which it was initially designed and improved student performance and motivation.

Carroll College has successfully offered an undergraduate degree in Computer Science for nearly 20 years. In 1998 we began to investigate the possibility of offering a Master's program in Software Engineering. The program will be for professionals with industry experience who would attend part-time. A proposal was developed and has been approved by the necessary internal bodies and, once approval is obtained from the North Central Accrediting agency, we will be able to go ahead and offer the degree. This academic year, Carroll is beginning to offer some of the introductory courses for the degree on a diploma basis.We regard this workshop as an opportunity to see what other people are doing in the area of graduate software education and come to it not with a 'position paper' per se but with a list of questions and topics on which we are eager to hear others' positions.

This poster reports on work in progress on the implication of thinking and learning styles on the modelling of Object-Oriented Systems. In particular, analyses of learning modalities are presented and then considered in light of using the Unified Modelling Language (UML) as a tool for system modelling. The results of testing UML CASE tool learners will be available before the conference.

As more software support tools become available, the construct ion of support environments by integration of ezisting tools becomes more desirable.The European project "Broadband Object-Oriented Service Technology" investigated the adaptation and integration of existing software tools to support telecommunications service creation.The investigation covered different approaches to adapting and integrating existing tools to form a service creation environment.The earliest environment encapsulated a wide range of these tools within an environment called EAST, supplied by the Soci6t6 Frangaise de G&ie Logiciel.While EAST provided a number of benefits, the users of the environment expressed a desire for small special-purpose toolkits which were created by the tool-to-tool integration of specific tools.These toolkits were used on their own, and were also encapsulated within EAST.With the advent of Tel, a language which facilitates tool programmability, it became possible to create programmable "capsules", and these were used for later encapsulations within EAST.Tcl also made it possible to create more flexible toolkits by direct toolto-tool integration.Experiences with all these different approaches are presented here, and future directions are discussed.q