Unlinked Referents

The tires need to be replaced.
They're no longer acceptable for the purpose of the duck.
He can't fathom why they can't buy the coffee with them.
They won't enjoy it unless it has lots of whipped cream.
It's funny that the coffee have such a strong preference, and he finds that unfortunate.
He prefers them when they float.

No Silver Lecture

Essence and Accidents of Computer Science Education

Abstract

This is a survey paper of modern topics within computer science education, specifically as they pertain to CS1 and CS2. Presented herein are the resources and references necessary to assess what enhancements can be made to an existing CS1 or CS2 course, and to receive a sufficiently detailed overview of the potential consequences of alternate methodologies. In addition to course-specific topics, this survey also investigates many of the common difficulties and hindrances facing students of CS1 and CS2. Where solutions to these difficulties are known, solutions are presented.

1. Introduction

With a tip of the hat to Fred Brooks (1), this paper is a survey of current the topics in computer science education as they pertain to CS1 and CS2. Many papers have been written over the past several years which address topics within computer science education, the challenges it faces, and both hypothetical and well-tested methods of improving its prospects. There is now sufficient research in the field to justify assorted conclusions about computer science education, and to remark on specific educational needs. We can use this data to formulate categories for the challenges relating to CS education, and make clear statements about simple changes which can be effected in order to produce substantial results.

2. Background

The truth of the matter is that the quality of computer science education is suffering from a trend of dropping enrollment (2), (3), poor gender diversity (2), (3), and a great deal of infighting and inconsistencies relating to what pedagogical techniques are most appropriate (4).

CS1 and CS2, as defined by the ACM (5), are the focus of the bulk of the educational research in the field. This seems appropriate, as these classes are not only the foundation classes for computer science which are experiencing severe dropout rates and gender diversity issues (2) (3), but also these classes are frequently offered to non-computer science majors as their introduction and often entire education within computer science.

No Silver Bullet (1) is a software engineering article which defines the essential and accidental difficulties within software engineering. Essential difficulties are those inherent in the field, while accidental difficulties are implementation-bound. Attacking the essence is a challenge, but the accidents can be methodically minimized. A parallel can be drawn with computer science education. Essential difficulties within computer science education include the task of conveying knowledge and skills to a student, the amount of practice required by a student before they can master a skill, the process of conveying mental models and constructs which the students can use to understand the material, conveying the concepts of object orientation or imperative program flow, etc. Accidental difficulties are therefore bound to implementation and circumstance: Computer Science doesn’t appeal to female students (2) (3) (4), the homework time is spent disproportionately on debugging (6), students feel intimidated by CS majors when taking CS classes (3), the chosen language has convoluted syntax, etc.

3. Defining CS1 and CS2

CS1 and CS2 derive from a set of curricular models proposed within the 2001 Computing Curricula Final Report, as set forth by the ACM (5). CS1 and CS2 are intended to function as the first two introductory courses for the field of computer science.

4. Implementation Strategies for CS1 and CS2

Implementation strategies are accidental! They all have the same ultimate goal, the question is merely where to begin.

The Computing Curricula Final Report proposes six potential implementation strategies for these introductory courses: Imperative-first; Object- first; Functional-first; Breadth-first; Algorithms-first; Hardware-first (5). Based on the literature surveyed, the Imperative-first strategy is the most common implementation choice, followed by Objects-first. The other implementation strategies listed were not frequently mentioned or addressed within the literature surveyed. In addition to these six basic strategies, some promising new strategies which have been proposed: Components-first and Games-first.

4.1 Imperative-First

The imperative-first approach is the most traditional model for teaching CS1 and CS2 (5). ACM’s computing curricula notes this approach as having significant disadvantages in the context of eventually teaching object orientation. The curricula further states that if the imperative-first approach is applied, students will require additional training in object oriented programming at an intermediate level. A common argument for the imperative-first approach is that by avoiding the added complexity of object oriented syntax, students are able to begin programming earlier. Since programming is a key skill which requires a lot of practice, introducing it early is beneficial (5).

Stuart Reges provides evidence in favor of the imperative-first approach, but advocates using Java (4). Reges found that teaching object oriented principles early was proving to be too difficult for students in CS1, and CS2 suffered as a result. In an effort to stabilize his university’s failing curriculum, Reges reverted CS1 to the imperative-first approach, but adopted Java as the course language. The primary motivation for using Java was to give students experience with the language prior to needing it in CS2. The Java code written in his CS1 class was primarily procedural java code- static functions. Reges admits to the complexity overhead in using Java, but notes that his students did not seem to mind it. The procedural Java CS1 course resulted in a significant improvement in student feedback relative to both the previous object-oriented Java CS1 course and the procedural C CS1 course.

Teaching CS1/CS2 via an imperative-first methodology is certainly feasible, and it is not uncommon for alternate pedagogical methodologies to fail to surpass the par of Imperative-First.

4.2 Objects-First

The Computing Curricula Final Report’s objects-first model is intended to emphasize object-oriented programming and design immediately, and teach control structures and programming practices as secondary topics motivated by OO’s need for them. The report cites the complexity of object oriented languages, such as C++ and Java, as a chief disadvantage to this approach.

A particularly insightful case study of implementing an object-first approach is documented in Object Orientation in CS1-CS2 by Design (7). In iterating upon attempts to build an object-oriented CS1/CS2 sequence, they came to discover that many of the existing approaches and supporting textbooks for an object-oriented introductory class, while teaching object-oriented concepts, did not approach the material in an object-oriented way: procedural programming is taught, and then object oriented concepts are built upon it. Iterating further, they found that introducing object orientation early was superior, however the point at which students transition from procedural to object-oriented methodologies persisted as a difficulty. They then moved to a substantially-more-successful method which involves postponing procedural programming topics until after object-orientation has been presented. In spite of concerns for the transition from object-orientated to procedural code would be as difficult as the inverse, this method resulted in substantially increased student comprehension. They hypothesize that making object-orientation a student’s first experience with computer science causes them to have “objects on the brain” – object models become their intuitive structure for thinking about computer science, and other computer science topics, such as procedural programming, are motivated by their necessities within object-oriented code. They also hypothesize that when students learn procedural programming methods first, they have trouble understanding the motivation for object orientation and view the increased syntax complexity as an unjustified burden.

Goldwasser and Letscher also provide evidence in favor of an objects-first approach to CS1 (8). Their approach in noteworthy because they apply and recommend Python as a programming language for CS1.

4.3 Components-First

Components-first introductory computer science classes are intended to focus on the libraries, API’s, and other common component infrastructures which are in common use by the software engineering profession (9). Components-first approaches are thus highly pragmatic, and equip students the ability to compose software applications from existing components. Two independent components-first approaches are surveyed within Components-First Approaches to CS1/CS2: Principles and Practice (9), and some of key elements to the components-first approach are established:

4.3.1 Client-View-First Pedagogy

Students are taught to understand components not by studying their implementations, but instead by studying their interfaces. Students are treated as clients seeking a necessary component, are provided said component, and must evaluate its usefulness and abilities based on how they can work with the interface. Only after the interface has been sufficiently motivated and applied do students switch roles to that of the implementers, and now must create the underlying structure which fulfills the interface.

4.3.2 Pointers

By delaying implementation of underlying component classes, the necessity of teaching pointers is also delayed. This delay has allows students more time to become comfortable with their programming language and its debugging techniques prior to studying pointers. The delay can also be used to motivate the fact that the primitive pointer-based data structures are frequently available through component libraries.

4.3.3 Program Complexity

Because students are working with existing component libraries, their assignments can more easily be tailored to creating useful, complex software. This tends to dispel notions that the techniques they learn are only applied in “toy” programs.

4.3.4 Data Types

Introduction of the array data type is delayed. This provides students with the ability to learn data types at a higher level of abstraction and focus on common data type manipulation techniques such as iteration and recursion. Arrays are introduced later not as a commonly-used data type, but rather as a data type which is motivated by its performance properties.

Howe et. al. conclude that the components-first approach is a legitimate approach to CS1 and CS2. Reflecting on the difficulty and perceived resistance to switching an existing CS1/CS2 sequence to a components-first methodology, they assert adopting Client-View-First pedagogy would be of significant benefit for any object-oriented introductory computer science course.

4.4 Games-First

Scott Leutenegger and Jeffrey Edgington of the University of Denver argue for a Games-First approach to introductory programming classes (2). Postulating that the concerns over imperative-first versus objects-first are less important than the types of assignments and examples provided to their students, they’ve constructed a 2D-game-oriented CS1 course taught using Actionscript/Flash and C++/OpenGL. Having merely refocused the course content to game development, but still teaching and testing on their standard technical content, Leutenegger and Edgington report a comprehension increase in all of their course topics, as well as increased student retention and substantially increased positive feedback from their female students.

5. Accidents of CS1 versus CS2

Although they are commonly spoken of jointly, there are several specific differences between CS1 and CS2 which give rise to distinct accidental difficulties for each course.

5.1 Addressing the accidental difficulties of CS1

CS1 was not constructed with the intention of functioning as a stand-alone course capable of preparing students to program professionally (10), (5), (3). However, as computers become more and more a part of everyday life, the field of computer science is becoming ever more interdisciplinary. Unlike in most other engineering disciplines, there is now an expectation of achieving a base-level proficiency after taking a single introductory computer science course (10).

While it is desirable to construct a CS1 course which most benefits students who progress through the computer science major, it is now also a necessity to cater to students who expect to be able to produce meaningful software after having taken only CS1. It is thus a challenge to produce meaningful course material which caters to the diverse population of students who desire basic computer science training.

One solution is to provide different CS1 courses to different student demographics (3). A simple division is to split CS1 based on whether or not the students in attendance are computer science majors. The non-majors section, then, would be able to focus simple and pragmatic aspects of computer programming, such as writing simple scripts and applications, while the majors section could devote more time building skills that will be necessary in future computer science courses. Further division may also be relevant- provide CS1 courses for students specifically interested in image and video manipulation, web development, audio effects and manipulation, etc. While this approach is likely to be beneficial (3), it sidesteps the problem of students being dissatisfied with the content of existing CS1 courses.

Another approach is to attempt to teach CS1 in an inherently more pragmatic fashion. The components-first methodology is an example of an implementation technique which provides this (9). A smaller change which can make CS1 inherently more pragmatic is to teach the course using an inherently more pragmatic language. Scripting languages, especially Python, are considered especially well suited to this task, (3) and (11), because of their low overhead in creating simple applications.

5.2 Addressing the accidental difficulties of CS2

As CS1 and CS2 are designed to be taught in a sequence (5), CS2 is inherently dependant on CS1 succeeding in conveying necessary prerequisites.

5.2.1 Language

CS2 courses usually incorporate more advanced language features than are covered in CS1. Further, it can be the case that the language students were taught in CS1 is different from the language being used in CS2. Unfortunately, students cannot learn a second language in a primarily independent fashion (10), and therefore the CS2 course must either ensure that its students are above a minimum skill level with the language to be used, or part of the CS2 course must be focused on teaching the language required.

While this may suggest a set of standards to which CS1 must conform (such as teaching the language that will be employed in CS2), it is not the case that the language chosen in CS1 affects student performance in CS2. To reiterate this astonishing finding: The programming language used to teach CS1 does not have a statistically significant impact on the performance of students in CS2 (11), (12). Further, one study finds that the paradigm (procedural versus object-oriented) chosen for teaching CS1 does not have a statistically significant effect on student performance in an object-oriented CS2 class (12).

This accident derives from the programming language which is chosen for CS2, and what supporting resources are provided for students learning this language. These topics are discussed in sections 6 and 7.

5.2.2 Inadequate preparation

It can also be the case that students entering CS2 are not adequately prepared to be taught the material. This issue is unavoidable, as CS2 students may have taken different CS1 classes, or no CS1 class at all. One promising approach to this difficulty is to provide a bridge course between CS1 and CS2.

To address the issue of many of their students not possessing an adequate mastery of CS1 material in their CS2 courses, and fed by the common student complaint that the examples used in CS1 and CS2 were abstract and non-compelling, Scott Leutenegger of the University of Denver developed a game-oriented CS1 to CS2 bridge class (13). The goals of this class were to “solidify CS1 concepts, provide concrete examples rather than abstractions, add some new topics, motivate the need for CS2, and offer a class that is fun for most students.” The course was taught using Actionscript/Flash. Anecdotally, this class appeared to be of major benefit to CS students.

It may be that CS1 is simply insufficient preparation for a significant amount of students who are entering CS2. If this is the case, teaching a bridge course, such as the one described above, could have a very substantial impact on student performance in CS2. It seems reasonable to claim that developing and offering a meaningful bridge course is substantially easier than reconstructing and optimizing a CS2 course, especially considering that both CS1 and CS2 may be taught differently by different instructors, and therefore guaranteeing their compatibility would be impossible.

Aside: As students are typically not allowed into CS2 without either CS1 or other programming experience, data on the performance of students who are introduced to computer science via CS2 is lacking. It would be a wonderful sanity check to be able to know how much of an affect CS1 has on student performance in CS2.

6. The role of Teaching Assistants, recitations, and labs

Another accidental difficulty of computer science education is quality control over the TA’s and lecturers who interact with students. Many CS1 and CS2 courses include a computer lab or recitation component, and this component of the class is often neglected during curricular innovation of CS1/CS2. This neglect is odd, given that labs are a key source of hands-on exposure to course content and that an effective laboratory experience can free up lecture time to cover more advanced topics (14). Indeed, only one of the papers surveyed attempted to integrate new lab and recitation techniques with their course experimentation on course experience (15). Presented here are two novel approaches toward enhancing the experience of labs and recitations, one of which is not a curricular development but rather a technique which is supportive of more rapid course innovation.

6.1 Students as Presenters

It is difficult to rapidly develop the content of CS1 and CS2 courses because as the courses develop and follow new approaches, so must all of the supporting faculty, staff, TA’s, etc. To address this issue, Robbins et. al. propose the use of students as presenters within CS1 and CS2 laboratory sessions (14).

Robbins et. al. feared for the quality of their students’ laboratory experiences. As curricular changes were made and as the software used in labs became more sophisticated, teaching assistants are having to spend increasing amounts of time troubleshooting software issues and otherwise managing lab affairs. Coupled with this, it’s also difficult to assure the quality and competency of TA’s, especially as material evolves- it is too much to expect the TA’s to grade, teach, run the lab, and also have to learn course material at a faster pace than the students. The proposed solution, then, is to have TA’s drop back to a supportive role of smoothing out the technical issues that arise during the laboratory sessions and working as graders. To replace the teaching role of the TA’s, student presenters would be hired from the pool of students who excelled in a previous iteration of the course. These presenters would be paid, and responsible for teaching a laboratory session on a specific topic. Because these are lab sessions for CS1 and CS2, the student presenters who receive a 4-year degree in computer science will have the three years following their initial participation with the course to iterate on and enhance their presentations.

With this model, a change in course content no longer invalidates the qualifications of course TA’s, instead it merely invalidates the necessity of the student presenters who focused on the material which is no longer relevant. Since a new pool of candidate student presenters is supplied after every course offering, new topics can quickly gain student presenters to cover them.

After implementing student presenters for their CS2 class, Robbins et. al. surveyed students and asked them to compare their experiences with the CS2 labs with their past laboratory experiences (such as CS1 labs). The response to having the student presenters was overwhelmingly positive, and they were especially grateful of having two teachers available in the laboratory (the student presenter and the supporting TA) because it allowed the TA to answer questions on an individual basis while the presenter could progress with material.

A downside to this approach is the funding expenditure relating to hiring the student presenters. For each presentation, the students were paid two hours of preparation. The total expenditure of Robbins et. al.’s experiment came to $12,000 per semester, but also included the salaries of student tutors who staffed the lab 105 hours per week (14 hours per day).

6.2 Think-Alouds

Inspired by the aforementioned work of Robbins et. al., Naveed Arshad has created a recitation experience based on using Think-Alouds (15). A Think-Aloud is a protocol that requires a subject to work through a process while verbally explaining all of the thoughts they have and methods they employ while solving the process (15). Arshad’s intent is to use Think-Alouds as a method of conveying computer science related problem solving skills during the recitations of his CS2 course.

High quality TA’s were selected to act as the Think-Aloud subjects. These TA’s were exceptional graduate students who have had many years of programming experience and often also had experience in industry. After training the TA’s on the Think-Aloud protocol, the TA’s would hold Think-Aloud based recitations based on the preceding lecture’s material. They were asked to select a significant problem within the domain currently being discussed, and would solve it during recitation using the skills that the students had been taught. This allowed for the students to observe the thought processes of the TA’s as they decomposed and solved the problems.

The students reacted very positively to the Think-Aloud-based recitations, not only exhibiting superior problem solving skills, but also learning good code-writing practices based on the styles used by the TA’s. At the end of the course, students were surveyed and asked to rank the effectiveness of the various aspects of the course. The Think-Aloud recitations were the most highly ranked aspect of the course.

7. Choice of language

The choice of which programming language to use in a computer science course perhaps gives rise to the biggest accident in computer science education at the CS1 and CS2 level: Whatever language you pick must be taught to students. Recall that “students cannot learn a second language in a primarily independent fashion” (10). While there is some relief in knowing that both the language and the pedagogical methodology chosen for CS1 appears to be independent of student performance in CS2 (11) (12), the choice of language for CS1 and CS2 is still important. Language choice is known to impact student retention, perception of computer science, and overall performance within the class (4), (3), (2), (11).

Assessing the Ripple Effect of CS1 Language Choice by Dingle and Zander provides an excellent overview of the strengths and weaknesses of the commonly employed programming languages for CS1 as of 2001 (10). While their insights into C, C++, and Java maintain relevance, many of the languages that they survey are no longer mainstream. Further, since Dingle and Zander’s article, many new languages have come into focus as candidate languages for teaching CS1 and CS2.

7.1 C

Usage of the C programming language is a topic of much contention. Some argue that C is both inappropriate and harmful to teach in an introductory setting (6), but many agree that having some exposure to C is still a necessity for modern computer scientists (16). C is a significant introductory language in part because of its small yet powerful grammar (10) and the access that it provides to rudimentary pointer and memory operations (17).

A major criticism of C is that students spend an inordinate amount of time debugging minor syntactic errors as well as convoluted memory errors, and that this debugging process is both demotivating and largely unproductive (6), (10). Some argue that these are in fact positive traits of C: successful C programming requires careful coding practices and strong debugging abilities, and therefore teaching with C helps to convey these skills (17).

C is the only programming language discussed in this survey which is not object-oriented.

7.2 C++

As it is built upon C, C++ naturally shares most of the strengths and weaknesses of C. As with C, one of the most significant pedagogical reasons for choosing C++ is that in enables meaningful exploration of pointers and memory management (2). C++ also tends to be more strongly practical than C because in many industries, especially computer game development, C++ is still the primary language employed (2).

Some meaningful enhancements which C++ provides include enhanced IO, superior access to libraries (via the STL), enumerations, pass-by-reference parameters, and object orientation. Unfortunately, C++ is hailed as way too complex, and still provides many of C’s confusing components such as type casting, implicit type conversion, lack of error detection for array out-of-bounds errors, etc. (10), (18).

On the bright side, mastering C++ tends to make other languages seem easy by comparison.

7.3 Java

Java has been a major player in CS education for many years. This popularity exists partly because of Java being considered cutting-edge and “Cool” (19). Java is no longer a young language, and since its development, several new languages have emerged which have built upon and enhanced Java’s ideals.

While Java is primarily considered as an alternative to C++, some CS1 courses have found benefit in using procedural Java in place of C (4).

Garbage collection, superior String data types, better compiler and memory management errors, and a large body of libraries are among the chief reasons Java is selected. Because pointers are not practically accessible within Java, the ability to teach about pointers and memory management is greatly diminished. Java’s differentiation between objects and primitive types also contributes to student confusion (10).

7.4 C#

C# is a young language which is currently in its third release iteration. Although built to be syntactically similar to C++, C# is, at the basic level, very similar to Java. In 2002, Reges postulated that C# (then in version 1.0) could be a viable candidate for replacing Java as a language for CS1/CS2. The language features he cited as advantages of C#, all of which still hold in C# 3.0, include simpler IO functionality, a simpler Main(), a consistent object model, iterators and foreach loops (Java now has these, too), properties, reference parameters, and closures. (19)

Another advantage of C# which may not have been available during the time of Reges’ research is that C# supports pointers. By using the unsafe keyword, C#’s garbage collector can be instructed to consider part of your program to be unmanaged code. Within this unmanaged region, C++ style pointers can be created and manipulated outside of the restraints of the garbage collector. Although the syntactic overhead for pointers is higher than that of C or C++, C#’s pointers still provide a pedagogical playground for pointer and memory-management based topics.

A point against C# is that it is not a truly cross-platform language, and while efforts exist to create C# environments on non-Windows systems, Java is more compatible across platforms.

7.5 Python

Python is rapidly emerging as a very viable choice for teaching CS1 and CS2, but it is especially receiving attention for its usefulness in CS1. Python’s nature as an interpreted scripting language makes it ideal for students who are first learning to write code. There is little to no garbage code overhead with python- the language lends itself to very concise statements and syntax. The interpreted nature of Python means that students can run the Python interpreter, type code, and receive line-by-line feedback on the results of their input. Python is also a heavily object-oriented language, however, unlike Java and C#, the additional syntax imposed by the object orientation is basically nil. It can also be argued that python is a substantially motivating and practical for students to learn. (11)

7.6 Actionscript (with Flash)

Actionscript can be an immensely fun language to learn and work with, and this is a great reason to choose Actionscript for CS1 or CS2. There is very low overhead for getting a Flash project up and running, interactive, and with visual feedback. In some cases, the project can be composed entirely using the Flash IDE. Flash can also be very attractive to students because of the ease of creating and sharing their resulting flash files. (13)

The object model within Flash is highly conducive of event-driven programming, and if Actionscript is used, it is quite necessary to instruct students on event-driven programming. Flash also has the “feature” of being quite slow- this can be put to good effect by using the speed limitations of Flash as motivators for using superior algorithms. (2)

Unfortunately, Actionscript can be very difficult to debug. The Flash compiler is notorious for generating code which can fail silently. Further, transitioning from Actionscript to a C++ style language has been shown to be unintuitive. (13)

8. Retention Efforts

A common variable measured in course development efforts for CS1 and CS2 is the effect of the course on student retention within CS (20), (21), (22), (13), (3). While it is amiable to aspire to a singular course to curb student retention issues in CS, the potential impact of student outreach programs and cohesive departmental tutoring and outreach efforts are also quite substantial (23), (14). Jeffrey Popyack argues that an ACM-Women’s chapter is a strong benefit to women in computer science because it provides a community of same-sex peer support. (24) Orientation activities, such as the Scavenger Hunt (23), can be highly impactful. Student moral is certainly an accidental difficulty within computer science education, but altering teaching techniques is among the narrowest ways of addressing it. Certainly a multi-faceted approach is necessary to improve retention and gender diversity issues within computer science, however high-impact retention efforts such as supporting student groups and hosting orientation activities are likely to be much easier to implement than redesigning CS1 and CS2 into the ultimate collaborative, educational, and social experiences.

Can alterations to the teaching methodologies of CS1 and CS2 improve retention? Yes, and these alterations are beneficial to pursue. It should just be considered that perhaps department-level involvement is a more substantive channel through which to reach students.

Among the most consistent methods of improving student retention, morale, and community via classroom experiences is to have courses involve collaboration and teamwork.

In Affective Assessment of Team Skills in Agile CS1 Labs (20), McKinney and Denton experimented with using agile techniques to host project teams in CS1, hypothesizing that the team aspect of the course would be of special benefit to the women and minorities in the class. They allowed students to form their own five to nine person teams, and then lead the teams through many of the practices of agile software development: pair programming, stand-up meetings, test-driven development, etc. After leading the teams through three project iterations, the teams were surveyed. Distinctive problems arose from allowing teams to self-form: specifically, skill levels were not appropriately matched and many teams suffered as a result. There were many situations where team members were rude and unethical, their article hints at several students who they felt were unfit to work with others. In spite of these disturbing behaviors, students in the class exhibited increased senses of comfort and belonging as a result of the team activities.

Agile methods may or may not be ideal for approaching teamwork in CS1, but it seems that even in what appear to be strenuous collaborative efforts, benefit arises.

9. Comfort, and intimidation, and interest

Gail Chmura is a high school teacher in Vienna, Virginia. She teaches introductory computer science to 135 students every year. While it is rare for her students to have programming experience, many of them have experience with computer games. When she starts her course, her students who have had computer experience are, as she puts it, “ready to go”. The students without computer experience are timid and anxious- though they are no less prepared for the material than the other students, the burden of intimidation weighs on them. Investigating her students further, she found all of her students could learn the material - they just required different amounts of support, time, and paces of work. She also found that there were no performance differences between males and females. (25)

Does intimidation fade after high school? No. Intimidation and attitude are present factors in the performance of college-level students studying computer science (22), (3). How can students be made more comfortable in computer science classes?

9.1 Comfortable Questions

Forte and Guzdial found that by teaching a CS1-equivalent course with only non-CS majors enrolled eased tension and made students feel more comfortable about asking questions and participating in class. (3) They also provided students with a web forum which they could use to communicate (anonymously, if desired) with each other about class topics. This forum successfully facilitated communication between students who were otherwise too shy to ask what they perceived as “stupid questions”.

9.2 Comfortable material

Another group found that comfortable assignment material is a significant factor in student comfort and interest. Faced with a class of mixed-background students, they came to learn to omit mathematical topics from their computer science assignments and postpone math-dependant topics until later in the curriculum. In place of math, assignments were built around game simulations and simple software applications. As a bonus, students who were bad at math became motivated by their newfound abilities as algorithmists. (26)

9.3 Intriguing content

Thomas Standish and Norman Jacobson of UC Irvine were disappointed with their students’ lack of interest in theoretical computer science. Hypothesizing that computer science theory was not being sufficiently motivated by teaching standard algorithms, they decided to incorporate an O(n) sorting algorithm, ProxmapSort, into their CS2 class. They anecdotally exclaim “Cool algorithms really do show that theory is cool!” (27)

The most painfully obvious statement of this survey paper is about to be presented. Here it is: Presenting interesting material to students increases their interest in the field of study. Ergo, it is advisable to teach interesting things.

9.4 Media and Image Processing

An increasing trend in student engagement is linked to media and image processing. Some hypothesize that using media as a conveyance mechanism for computer science allows students to feel more artistic about programming, while others are content to realize that media is a domain within which most people are comfortable interacting (3), (28), (17).

Forte and Guzdial launched what appears to be the first significant effort in teaching CS1 through media and image manipulation, and their results from teaching the course to strictly non-CS majors were overwhelming positive. One year later, Wicentowski and Newhall developed and taught a similar course, but this time targeted as a true CS1 course. Their results, too, are overwhelmingly positive. Another year passes and another course succeeds: Matzko and Davis teach an image manipulation CS1 course using C. Their results are less overwhelmingly positive, as a substantial amount of their students seem to have struggled with implementations. Even so, student feedback was positive and student motivation was high.

Media processing is a powerful motivator for teaching CS1, and sufficient supporting materials now exist that new CS1 courses have many examples to draw upon.

9.5 Games

Game development has been found to be another highly motivating angle from which to approach computer science education. In addition to the visual feedback and creative outlets provided by media processing, game development allows for opportunities to illustrate, concretize, and motivate computer science topics as aspects of game play (13).

As interest in this field grows, educational infrastructure for is also growing for the purpose of assisting game-inexperienced professor with incorporating games into their lectures. Lewis and Massing provide an infrastructure for use in running a semester-long game development project (29), while Sung and Panitz are working to provide sets of modular game-oriented assignments which are designed to be selectively implemented by interested professors and they move toward game-oriented teaching. (21).

To dispel any myths on the subject: Games are not male-biased. While it is true that certain genres of games have been anecdotally known to express gender bias, most casual games are profoundly gender-neutral. “Women play games too.” (2)

10. Conclusions

10.1 Core Insight

All of the data presented in this survey is inherently skewed. This skew exists because the researchers involved in writing these articles are people who are taking an active interest in the teaching methodologies of the CS1 and CS2 courses at their university. Regardless of their approach, it is reasonable to expect that any lecturer who commits him or herself to improving the quality of their students experience will succeed to some extent.

The most meaningful results from this survey, then, derive from the sets of tools presented. A CS1 course seeking to enhance its curriculum should be able to find sufficient data within this survey to be able to ascertain what promising approaches are available. By following the references provided herein, sufficient knowledge can be gleaned to support the development of any of the pedagogical styles and techniques surveyed.

10.2 Other Findings

10.2.1 C#

Aside from cross-platform concerns, C# is at least as viable of a pedagogical language as Java. C#’s simplified IO, consistent object model, and ability to work at the pointer-level should set it above Java as an introductory language.

10.2.2 Object-first methodologies

A recurring failure in object-first approaches results from misconceptions of the goals of object-first pedagogy. Object-first does not entail teaching rudimentary procedural techniques and then rapidly advancing to object-oriented programming. Object-first’s strength derives from teaching and motivating object oriented methodologies before addressing procedural topics.

10.2.3 Component-First methodologies

While substantial results of their effectiveness remains to be had, initial findings on this style of teaching are quite encouraging. The Client-View-First pedagogical technique is capable of being applied to all introductions of object orientation. Applying this technique could provide a general enhancement upon all standard methods of object-focused teachings.

11. References

1. No Silver Bullet: Essence and Accidents of Software Engineering. Brooks, Frederick Jr. P. s.l. : ACM, 1987, Computer Volume 20 , Issue 4, pp. 10-19.

2. A games first approach to teaching introductory programming. Leutenegger, Scott and Edgington, Jeffrey. 2007, ACM SIGCSE Bulletin Volume 39 , Issue 1 , pp. 115-118.

3. Computers for Communication, Not Calculation: Media as a Motivation and Context for Learning. Forte, Andrea and Guzdial, Mark. Big Island, Hawai`i : IEEE Computer Society, 2004. Proceedings of the Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04) - Track 4 - Volume 4. p. 40096.1.

4. Back to Basics in CS1 and CS2. Reges, Stuart. 2006, ACM SIGCSE Bulletin Volume 38 , Issue 1, pp. 293-297.

5. Roberts, E., Ed. Computing Curricula 2001: Computer Science Final Report. New York : IEEE Computer Society, 2002.

6. C in the first course considered harmful. Johnson, L F. 1995, Communications of the ACM Volume 38 , Issue 5, pp. 99-101.

7. Object Orientation in CS1-CS2 by Design. Alponce, Carl and Ventura, Phil. Aarhus, Denwark : ACM, 2002. Proceedings of the 7th annual conference on Innovation and technology in computer science education. pp. 70-74.

8. Teaching an object-oriented CS1 - with Python. Goldwasser, Michael H and Letscher, David. Madrid, Spain : ACM, 2008. Proceedings of the 13th annual conference on Innovation and technology in computer science education table of contents. pp. 42-46.

9. Components-First Approaches to CS1/CS2: Principles and Practice. Howe, Emily, Thornton, Matthew and Weide, Bruce W. Norfolk, Virginia, USA : ACM, 2004. Proceedings of the 35th SIGCSE technical symposium on Computer science education. pp. 291-295.

10. Assessing the ripple effect of CS1 langiage chouce. Dingle, Adair and Zander, Carol. Oregon Graduate Institute, Beaverton, Oregon, United State : Consortium for Computing Sciences in Colleges, 2001. Proceedings of the second annual CCSC on Computing in Small Colleges Northwestern conference. pp. 85-93.

11. Python CS1 as preparation for C++ CS2. Enbody, Richard J, Punch, William F and McCullen, Mark. Chattanooga, TN, USA : ACM, 2009. Proceedings of the 40th ACM technical symposium on Computer science education. pp. 116-120.

12. Has the paradigm shift in CS1 a harmful effect on data structures courses: a case study. Gal-Ezer, Judith, Vilner, Tamar and Zur, Ela. Chattanooga, TN, USA : ACM, 2009. Proceedings of the 40th ACM technical symposium on Computer science education. pp. 126-130.

13. A CS1 to CS2 bridge class using 2D game programming. Leutenegger, Scott T. 2006, Journal of Computing Sciences in Colleges Volume 21 , Issue 5, pp. 76-83.

14. Solving the CS1/CS2 lab dilemma: students as presenters in CS1/CS2 laboratories. Robbins, Kay A, et al. 2001, ACM SIGCSE Bulletin Volume 33 , Issue 1, pp. 164-186.

15. Teaching programming and problem solving to CS2 students using think-alouds. Arshad, Naveed. Chattanooga, TN, USA : ACM, 2009. Proceedings of the 40th ACM technical symposium on Computer science education table of contents. pp. 372-376.

16. Spolsky, Joel. Advice for Computer Science College Students. Joel On Software. [Online] 1 2, 2005. [Cited: 3 18, 2009.] www.joelonsoftware.com/articles/CollegeAdvice.html.

17. Teaching CS1 with Graphics and C. Matzko, Sarah and Davis, Timothy A. 2006, ACM SIGCSE Bulletin Volume 38 , Issue 3 , pp. 168-172.

18. Some Deficiencies of C++ in Teaching CS1 and CS2. Agarwal, Achla and Agarwal, Krishna. 2003, ACM SIGPLAN Notices Volume 38 , Issue 6 , pp. 9-13.

19. Can C# Replace Java in CS1 and CS2? Reges, Stuart. Aarhus, Denmark : ACM, 2002. Proceedings of the 7th annual conference on Innovation and technology in computer science education. pp. 4-8.

20. Affective assessment of team skills in agile CS1 labs: the good, the bad, and the ugly. McKinney, Dawn and Denton, Leo F. 2005, ACM SIGCSE Bulletin Volume 37 , Issue 1, pp. 465 - 469.

21. Assessing game-themed programming assignments for CS1/2 courses. Sung, Kelvin, et al. Miami, Florida : ACM, 2008. Proceedings of the 3rd international conference on Game development in computer science education. pp. 51-55 .

22. CS Minors in a CS1 Course. Kinnunen, Päivi and Malmi, Lauri. Sydney, Australia : ACM, 2008. Proceeding of the fourth international workshop on Computing education research. pp. 79-90.

23. Scavenger hunt: computer science retention through orientation. Talton, Jerry O, et al. 2006, ACM SIGCSE Bulletin Volume 38 , Issue 1, pp. 443-447.

24. Take your daughters (and sons) to work: and leave them there. Popyack, Jeffrey. 2008, ACM SIGCSE Bulletin Volume 40 , Issue 2, pp. 22-23.

25. What abilities are necessary for success in computer science. Chmura, Gail A. 1998, ACM SIGCSE Bulletin Volume 30 , Issue 4, pp. 55-58.

26. Computer Science at Staten Island Community College: Teaching Computer Science in an open admissions environment. Chi, Emile C. s.l. : ACM, 1974. Proceedings of the fourth SIGCSE technical symposium on Computer science education. pp. 48-52.

27. Using O(n) ProxmapSort and O(1) ProxmapSearch to motivate CS2 students (Part I). Standish, Thomas A and Norman, Jacobson. 2005, ACM SIGCSE Bulletin Volume 37 , Issue 4, pp. 41 - 44.

28. Using image processing projects to teach CS1 topics. Wicentowski, Richard and Newhall, Tia. 2005, ACM SIGCSE Bulletin Volume 37 , Issue 1 , pp. 287-291.

29. Graphical game development in CS2: a flexible infrastructure for a semester long project. Lewis, Mark C and Massingill, Berna. Houston, Texas, USA : ACM, 2006. Proceedings of the 37th SIGCSE technical symposium on Computer science education. pp. 505-509.

30. A comprehensive project for CS2: combining key data structures and algorithms into an integrated web browser and search engine. Newhall, Tia and Meeden, Lisa. 2002, ACM SIGCSE Bulletin Volume 34 , Issue 1 , pp. 386-390.

31. Scaffolding for Multiple Assignment Projects in CS 1 & CS 2. Kussmaul, Clifton L. Nashville, TN, USA : ACM, 2008. Conference on Object Oriented Programming Systems Languages and Applications. pp. 873-876.

32. Games as a "Flavor" of CS1. Bayliss, Jessica D and Strout, Sean. Houston, Texas, USA : ACM, 2006. Proceedings of the 37th SIGCSE technical symposium on Computer science education. pp. 500-504.

33. Liberty, Jesse and Xie, Donald. Programming C# 3.0. Sebastopol, CA : O'Reilly, 2008. 0-596-52743-8.

The Business Plam

You’re approaching the podium, and your palms are a little sweaty. The lights are bright. It’s funny how you’re not confident anymore.  You decided against queue cards because it’s so much cooler to have memorized your presentation.  There’s some manner of slide deck being displayed behind you.  You start talking.  Things are going according to plan. You’re in control. Awesome.  Slide 2. You elegantly convey all you desire. Slide 3-5. People are interested.  The time comes to sell your product, your business plan. A couple people giggle- that subtle joke must have worked!  You catch a glance at your slide, its concise and critical title: Business Plam.

Feeling a little silly, your train of thought is jarred.  What was that point you were going to make? Crap, this isn’t going according to plan… you’re not in control any more. And now you’re uncomfortable. And your voice just cracked. And you stuttered. Crap.

There are two perspectives during a crappy presentation, the audience and the presenter. In a good presentation, there should only be one.  Let’s talk about control.

Of my hundreds of occasions speaking to a crowd, I have had perhaps 4 instances of everything going according to plan.  More frequently, things went according to plam.  For me, planning to be in control is a fallacy. There are people who excel at controlling a crowd, people who move with measured step and speak with graceful tongue, and these people I highly respect.  These people, to me, are actors. They are thespians.  Despite my occasional aspirations, I am not a thespian, and neither are the vast majority of presenters who I have witnessed.  Thespians can stay in control. I, and most likely, you, cannot.

During a good presentation, there is one perspective.

In the theatre, the perspective is that of the presenter.  You’re drawn into their world, their mind, and you and them become one.  Your thoughts are slave to the speaker, and you are in their control.  This works beautifully, but is hard to pull off.  Theatricality is a wonderful aspect of any presentation, but so is not sucking.

Another perspective can be that of the audience.  That person behind the podium? They’re just a marionette, and you’ve got a front-row seat with popcorn, a noisy neighbor, a fat guy pressed against you, and a set of strings.  Be your own audience, and make yourself laugh. Make yourself smile.  You don’t need to sell other people your ideas, you just need to sell them to yourself.  Hey look, the marionette misspelled ‘plan’'- what dance can we make it do to most please the audience? Pull the strings and reenact Barack- he could make it work, so your puppet can too.  This is easier.

I had a high school friend named Asael, or ‘Ace’.  He was in most of my presentation-heavy classes, and our approaches contrasted heavily.

I always had a plan. I had many plans. I knew how I wanted my presentations to work, and I knew that they could work beautifully. And every time I was in less than complete control, they didn’t.  I wanted to be a thespian, but I wasn’t good enough.

Ace was less formal.  His speeches were given with great comedic enthusiasm, and he was quick to laugh at whatever blunders might occur.  All things came in stride, and all things remained fluid.

My best presentations were better than his, but not by much. My presentation quality, however, varied wildly, and my worst presentations were useless.  His presentations didn’t vary much- If my presentations varied from 0’s to 10’s, he was pretty consistently hitting 8’s.

He taught me that, while control can be powerful, it’s most important to merely be able to laugh at yourself.  If you can do that, then your plams will come to fruition.

I’m a Deserter of the Holy Wars

No, not the Crusades.

Part 1: Suspicion and Allegiances

 

"You know computers, right?"

"Yeah?"

"Tell me something: What's wrong with Windows Vista?"

“uh… Well, when it was released it didn't have sufficient driver support, and this caused many unhappy compatibility issues. But really, that was to be expected- the same thing happened with XP when it was first released. Otherwise, I'd argue that Vista is better than XP in just about every way."

"I have Vista on my computer, and I hate it. I took a class about computers and the guy kept talking about all this advanced stuff and I couldn't understand him. He kept talking about folders! What's a Folder?!"

At this point I came to realize that her complaints really had nothing to do with Vista, it was just the name that she came to associate with everything that embodied her computer. Google is Vista, for her. She couldn't care less what a driver is, and in fact she'd probably be much happier not knowing.

Microsoft has fought a long and bloody battle to get people to associate computers with Windows, and Windows unlocking all of the great things that a computer can do. Apple is fighting a similar battle. I suspect that many of the people most affected by these campaigns are the people least capable of understanding the consequences of their brand choices.

I hypothesize that branding is a particularly convincing draft officer in the recruiting office for the operating system holy wars.

Consider the newb, eager and experimental. They are easily frustrated when software products fail to meet their mental models, and are frequently frustrated because their mental models of computer software are largely incorrect. They generate statements such as "I love/hate _____ because it sucks/rocks." Seeking affirmation, they google these phrases and find a community of users who have similar sentiments. They also find in this community the tech-savvy members who state more reasons why their opinion is correct. They find their appropriate cult, and their biases are formed. They even preach the gospel which they don't quite understand, "I hate Windows because it doesn't support virtual desktops!", and gradually gain the approval of their cult's luminaries.

A power user is merely a newb matured. Some are agnostic, some are atheist, but many are devout. They have reasons for their choices, but many fall victim to their religious doctrines.

Branding is powerful, any marketing person will agree. I have many brand preferences, and I have many brand insistences. It's easy to keep me completely satisfied with Dial Soap, but software products… not so much. 
 

Part 2: Fear and Loathing

Visual Studio and Eclipse are both awesome, as are Vim and Emacs.

Every programming language sucks, including yours, but the essence is becoming ever more approachable.

Every operating system sucks, but they're getting damn cool.

I would be afraid to work directly for Microsoft, and more afraid to work directly for Google.

Microsoft is interesting to me because of how big, old, and stereotyped it has become.  I view Microsoft kind of like I view the United States of America:

Overall, it has drastically improved my life, and there are many aspects of it which are absolutely fantastic. Many excellent people are associated with it, and it does many remarkable things which I would love to be involved in. It's also very, very big. It's so big, in fact, that bad people have snuck in. It's so big that it occasionally has to make decisions to which there is no answer which won't heartily displease many masses of people. It has its own culture, its own history, and its own unique way of existing in the world.

I would be afraid to work for Microsoft because I would be unable to defend it. I could not proudly state that I work for them without fear of rebuke, even though I would personally be delighted by the fact. I'm an engineer, and dreadfully afraid of attack dogs.

I would be afraid to work for Google because of its culture. Google: You are brilliant, and I like you, but I don't want to hang out with you because you pick on the big smelly kid, Mic. I agree that Mic is smelly, but I don't think it's very nice of you to pick on him. I've attended at least a half-dozen of your technical talks / recruiting sessions, and you always bring up the fact that he is smelly. There is a yak growing in your eye.

iGoogle: What The Hell?

Today, I find this in my iGoogle page:

A brand new chat interface which proudly announces to me that it doesn’t work.   The minimize button by it?  No, that doesn’t minimize the text.   Maybe I can turn it off in settings…

 

There.  There is the toggle.  Holy Crap Google, that is the most disgusting toggle UI that I have ever seen. Please tell me, is it standard convention for the bottom item to correspond with the left button, or the right button?

 

Google… WHAT?!

Windows 7 Beta

I’ve been using W7 as my core OS for about a week now.

Some highlights:

1. Redesigned Core Applications:

Wordpad, Calculator, Paint, Minesweeper, etc., have all been updated.  I find this delightful, especially the Programmer’s Calculator:

2. New core applications:

(some of these require downloads, others are already available in vista.)

These include sticky notes, DVD Creator (which is quite wonderful), and (my favorite) the math input panel.

Step 1:

Step 2:

Step 3:

3. Gui and navigation enhancements:

Keyboard shortcuts are a big deal, as are the lack of security notifications.  There’s too much for me to tackle writing about, but there’s still no virtual desktops.  The new taskbar interface keeps things clean, and the library system makes indexing work better.  Full screen previews of minimized items- very good.  Here’s a substantial statement:

It’s snappy, clean, and FAST. 

4. Compatibility wizard

Remember the compatibility settings which could be set for programs that didn’t quite work right?  It’s a wizard now, and it has a decent success rate.  This means a lot to me, as I frequently install antiquated games.

5. Bootup time:

Fastest yet, relative to hardware trends.

6. Performance:

Completely owns Vista.

Beta Issues:

Sleep, though overhauled and seeming to work better, doesn’t always properly awaken my SATA hard drive.  A cold boot is necessary to recover from this.  Also, MSN/Live Messenger spams me when I remove cd’s from my cd drive, but messenger has always had some amount of stupidity attached to it, so this isn’t really new.  Aside from those issues, the beta is wonderfully stable. All my drivers and software work just fine.

The only bluescreens I've encountered have resulted from trying experimental WDM drivers.

I encourage all Vista users to upgrade to W7Beta before they stop offering new keys.

http://www.microsoft.com/windows/windows-7/beta-download.aspx

P.S.  Do read the release notes.  There’s a trivially correctable bug related to playing music with WMP which can damage your files.  Fix that.

FogBugz + iGoogle = Win

I use the free student edition of FogBugz to manage my relatively busy schedule. It's pretty damn useful.

If you want one, just go to FogBugz.com and create a trial account. Once you're in the trial, go here:

I also use the iGoogle homepage to keep track of the assorted events that are of interest to me.

Until today, my 'homepage' has been set to a two-tab collection: iGoogle, and FogBugz.

But wait! iGoogle has tabs, and can embed RSS feeds! Saved filters in FogBugz can be viewed as RSS Feeds!

This enables the following:

1. My most important filters can live on my homepage!

2. I can have a FogBugz tab which can show me samples of the 9 top items from every filter that I care about(and also provide me with a quick link to FogBugz):

3. I can enter a detailed view of a given filter, thus gaining a complete view:
(…And I can click on the listed items in order to directly open them in FogBugz!)

Sweet.