Helping Students Succeed by Improving CS1 - A Case
Study
Robert Hatch
The University of Virginia’s College at Wise
One College Ave.
Wise, VA 24293
rjh7g@mcs.uvawise.edu
ABSTRACT
This paper discusses an attempt to boost retention and
better understanding of programming concepts by making
changes to a CS1 course. These changes included nightly
homework, more exams, and the addition of a lab hour where
students worked in teams to complete activities assigned.
Prior offerings of the course assigned weekly programming
assignments, three exams over the course of a semester, and
a final exam. The changes made to the course are compared
to prior offerings of the course, based on student perfor-
mance, as well as student feedback on the new aspects of
the course. The course continues to be tweaked, based on
student feedback, and the instructor’s in-class observations.
Keywords
C++, CS1, lab, student enhancement
1. INTRODUCTION
Within our department, there has been a shift in of focus to
find ways to both recruit more information technology (IT)
majors, as well as find ways to boost retention of students
who enter as IT majors. Our department loses many of
the students who take CS1 or CS2. Some of the reasons
behind the loss of potential majors include their inability
to understand how to program, which could be a result of
misgivings in high school, prior to their arrival at college.
Some students enter an IT field based on the reason that
they play video games and think they would like to major
in the field, without having any notion of all of the steps and
involvement necessary to create a successful video game.
One potential solution was to implement a lab hour, in ad-
dition to the three hours per week the students meet for
class. The lab hour perhaps needed to be a way to help
students with concepts they were struggling with during lec-
tures. The department hoped that this lab would help retain
more students as well as provide them with a better foun-
dation on programming principles before proceeding to our
CS2 course.
The remainder of the paper is divided up as follows: Section
2 discusses related work; Section 3 discusses the previous
format of our CS1 course, as well as our new format with
the lab; Section 4 shows changes in student performance,
as well as feedback about the new format; and Section 5
ponders future work.
2. RELATED WORK
The biggest factor considered was the addition of the lab
to the CS1 course. For students to succeed, the lab, in
combination with daily homework and quizzes, was critical.
2.1 Introduction of a Lab
Brown [2] believed that “most courses at the (CS1) level
should include laboratory sessions. These laboratories pro-
vide the student with the opportunity to gain practical ex-
perience by actually solving problems on the computer.” Ku-
mar notes that the Curriculum 91 report recommended in-
cluding hands-on lab experiences in introductory program-
ming courses. The idea of closed labs comes from this report;
these are fixed-duration lab sessions during which students
work on assignments under the supervision of faculty, in ad-
dition to their class assignments.
McCauley, et al. [8] were curious whether the effectiveness
of the lab hinged on the fact that faculty in charge of the
lecture are also in charge of the lab. In terms of perfor-
mance, both sets of students performed “equally well” when
they had the same person as lecturer and lab instructor than
when they had different faculty members in each position.
Ford, et al. [3] consider that the lab gives the instructor an
opportunity to see how well the lectured material is learned
and to work one-to-one with students, producing major ben-
efits: group work, collaboration, collaborative problem solv-
ing, and work in a controlled setting. Labs can be bene-
ficial to students, if they are structured properly, because
labs are more than just “homework assignment completion”
and “teacher-assisted debugging sessions,” as suggested by
Beaubouef and Mason[1]. Patitsas and Wolfman [10] dis-
cuss how to create effective closed labs in early CS courses.
The two note that CS educators believe labs might “dramat-
ically” improve interest in and perception of CS but also can
dissuade students if the lab isn’t helpful.
LeJeune [7] suggests that collaborative learning is a valu-
able educational tool for use in CS1. Collaborative learning
is defined as instructional methods whereby students are en-
couraged or required to work together on academic tasks.
2.1.1 Types of Labs to Consider
Soh, et al. [11] points out that labs foster cooperative learn-
ing, which is an “effective pedagogy for CS, producing signif-
icant gains in student achievement.” The authors note that
cooperative learning helps students understand that work-
ing in small groups helps them succeed in achieving tasks as
well as develop communication and problem-solving skills.
Walker [12] provides a roadmap of how to conduct a lab that
is based in active-learning experimentation. The observed
benefits of the lab include improved student syntax; positive
grades and positive, confident students; active learning; and
more time for faculty to contact and get to know students.
Lasserre [6] discusses the benefits of using team-based learn-
ing (TBL) on a first-term programming class. The first ex-
periences with computer science and programming should be
positive for students; their experience further shapes their
attitude toward the field and how it impacts the interest
and success of the student. Team-based learning (TBL) is
a teaching technique that places emphasis on applying con-
cepts as a means to learn. Its main objective is to test
the current understanding of concepts and applying newly-
acquired concepts on increasingly difficult problems, but stu-
dents need to come to class understanding concepts prior to
the lecture. Instructors found that students understood con-
cepts better when they discussed them with others in class.
Another direction to consider for instruction is the use of
studio-based learning (SBL). Narayanan, et al. [9] defines
SBL as an instructional technique that “emphasizes collabo-
rative, design-oriented learning.” SBL might have some merit
in CS1 courses. In a separate paper, Hundhausen, et al. [4]
explains the phases of the pedagogical code reviews (PCR)
as an extension to SBL: write, submit, review, feedback, re-
vise, and quality assurance. The PCR follows a similar path
to a formal code inspection.
2.2 Classroom Changes
A lack of practice and feedback exists in classes and labs.
Students have a right to have a knowledgeable programmer
look at their code and provide meaningful feedback. Instruc-
tors also might give more tests and pop quizzes if instruc-
tional time isn’t lost in class or on grading. Students have
poor project management skills; they are unable to estimate
the amount of time taken to complete a project, and they
wait until the last minute to start on assigned work [1].
Problem solving skills and logical reasoning required to be
successful in CS1 are mainly developed through large amounts
of practice [6]. Additionally, in terms of practice program-
ming, the greater number performed, the easier problems
seemed when they were encountered later [5].
3. COURSE FORMAT
This section details current and previous formats of our CS1
course.
3.1 Prior Offerings of CS1
Our CS1 course was a four-hour class that met three hours
a week. The course was taught using the following com-
ponents comprising the course grade: programming assign-
ments, exams at regular intervals, and a final exam, with
a smaller portion of each student’s grade based on partic-
ipation and quizzes, depending on the instructor. Regular
exams and programming assignments made up significant
percentages of the student’s final grade.
3.1.1 Grading
The programming assignments consisted of using tasks that
the students had learned recently, based on when the as-
signment was given. The exams consisted of these types
of questions: short-answer; correcting code questions; short
programming questions; a tracing question; and a long pro-
gramming question. The short-answer questions asked stu-
dents about concepts and sometimes asked them to provide
examples to further explain concepts. The correcting code
questions tasked the students to present a piece of code (ap-
proximately five lines) and find the problems with the code,
if any existed. If problems were present, students had to
supply the correct code. The short coding questions would
ask students to either write the necessary code snippets to
answer the task specified or rewrite a given code snippet
using a different structure (for instance, a “while” loop is
presented; rewrite this “while” loop using a “for” loop). The
tracing exercise required students to provide output for a
given code. The students earned points if they showed their
work. The last component, the long coding problem, asked
students to write an entire C++ program to solve the given
problem or task.
3.1.2 Class Structure
The structure of the class primarily used PowerPoint pre-
sentations and provided opportunities with in-class exercises
for students so that they could apply their knowledge and
understanding of concepts which had just been introduced.
The order of topics coincided with the format of the text-
book: variables and sequential statements, classes, selection
and iteration statements, functions, arrays, pointers and ref-
erences, and advanced class concepts.
Discussions of classes were split up because we wanted to
give students a foundation for their use - that they were
data types, just like integers and floating-point numbers, but
were different because they contained multiple pieces of in-
formation. Classes could more adequately describe a “thing”
than an integer, floating-point number, or character. Stu-
dents had difficulty completing early programming assign-
ments with classes because those concepts which would be
covered several chapters later in the text were introduced
in the chapter along with classes. This created the added
frustration of learning several concepts at once.
File I/O was introduced as a means to give the students more
interesting projects with large amounts of data. The stu-
dent’s job was to use compilation errors to figure out where
and why the errors were occurring. Strings were introduced
after arrays to give the students a sense that strings were
just an array of characters. The discussion of strings led to
giving students more interesting projects, similar to reasons
why File I/O was introduced.
3.2 Fall 2012 Offering of the Course
The students’ grades were assigned, based on a series of
tasks completed during the course of a semester. These tasks
included the aforementioned programming assignments, ex-
ams, and final exam, as well as a homework component, quiz
component, and lab component.
3.2.1 Grade Components
The homework component consisted of assigning program-
ming problems from the textbook that were due at a “ran-
dom” time the first half of the semester, usually on a Monday
with sufficient advanced warning. If students did not discuss
or understand concepts presented in class, the homework
due date was changed randomly to the end of class, and stu-
dents had to finish and turn in their homework by the end
of that class. This change was introduced mid-term. Grad-
ing homework was a quick “eye test,” and students earned
one of four possible grades: 100 - satisfactory completion;
50 - the program compiled but did not complete the task;
25 - the program did not compile; or 0 - no submission. The
homework component counted as ten percent toward the fi-
nal grade; the rationale was to make students practice more
often and to avoid last-minute work on assignments.
Another addition was quizzes, given on or around the mid-
point between exams; the first quiz was given at the end of
the second week of class. Questions asked were often short-
answer; the class had only half of a period (25 minutes) to
complete it. Some questions were conceptual, while others
required students to write code snippets. The purpose of
each quiz was to serve as a diagnostic for what students
needed to study for the next exam, so they only carried a
weight of ten percent toward the final grade.
A student’s lab grade was determined by his or her partici-
pation and impact in group discussions and work completed;
the grades were assigned by other students in the group. The
lab counted as 15 percent of a student’s grade.
Exams were altered somewhat; the code-correcting section
was dropped, and the long coding problem became a “prac-
tical problem.” Thus the exam was split into two parts:
a written component, which was closed-book, closed-note;
and a practical component, which was open-book, open-
note, open-computer and internet, but closed-neighbor. The
practical component was graded as completed/works (full
credit); compiles but doesn’t completely do the necessary
task (at least half-credit); and doesn’t compile (normally
one-third to one-fourth credit, unless there was a small syn-
tactical issue). Four exams (excluding the final) were given
over the course of the semester, based on the fact that stu-
dents had to digest so much information during the semester.
The exams were calculated as 30 percent of a student’s
grade.
The nature of the programming assignments remained the
same, and so did the final exam. Programming assignments
were weighted at 15 percent because they were the other
previous primary indicator of whether a student would suc-
cessfully complete the course. The final exam was worth 20
percent of the final grade.
3.2.2 Class Structure
The class was changed to de-emphasize the use of Power-
Point. Presentation files were available to students after
class, but they only summarized points covered. The course
made more use of writing points on a whiteboard, which en-
couraged students to take notes. The idea of having students
complete in-class exercises and review examples of code re-
mained. With the addition of quizzes, only half of available
class time could be devoted to a concept. These class days
became “problem days” when the instructor worked through
at least one or two problems introduced at the end of each
chapter in the textbook.
The lesson plan remains largely the same as prior course
offerings; the sole difference is the introduction of object-
oriented programming toward the end of the semester. The
rationale for this change was based on the fact that stu-
dents should be familiar and comfortable with many of the
programming concepts covered, including writing and call-
ing functions. Doing this allows the instructor to spend less
time reviewing material previously covered other semesters
related to the introduction of classes. This approach also al-
lows the instructor to cover interesting object-oriented con-
cepts in an unrushed setting, which is important for stu-
dents to grasp when they move on to CS2. Previously, stu-
dents might have received some instruction about destruc-
tors and default memberwise assignment. The way in which
the course has been retooled allows students to receive ad-
equate instruction in these concepts, as well as inheritance
and composition.
Our department changed the course with the introduction of
a lab component; as a result, students must meet for an addi-
tional hour. The initial intent of the lab was to have students
work in groups to examine each other’s code (code review)
to expose them to other ways of thinking and understanding
concepts. They were given checklists of questions each week,
and each statement needed only a yes/no response. Check-
list length increased as the semester continued; the students
covered more and sometimes complex topics. We wanted
them to see how others approached solving a problem. Some
lab sessions ended with nominating a “best of group” code
so that all students in the lab could see a particular solution
and why it was voted “best of group.” Sometimes the voting
was the result of well-documented code; at other times, it
was a unique solution. The last programming assignment
became a two-week project, so the final labs involved work-
ing in groups to write software that addressed a problem
assigned at the beginning of the lab period.
3.3 Spring 2013 Offering of CS1 Course
The grading scheme of CS1 did not change going into Spring
2013; all components from Fall 2012 were kept. The lab hour
alternated every week between the aforementioned code re-
views and a team coding exercise. The students responded
more favorably when asked at the end of the Fall 2012 term
about their experiences with the team coding activities but
not the code reviews.
The homework component was changed; homework was still
assigned at the end of every class, but it was due at the
beginning of the next class (unless it was a scheduled exam
day). Homework grading was altered. Randomly-examined
homework was graded using the 100/50/25/0 structure, as
discussed earlier. The remaining homework was graded for
completeness, verifying that students had turned in the as-
signment. Students did not like the fact that homework was
randomly due on a certain date without warning.
4. RESULTS
This section will detail the feedback received from students
concerning alterations to the course, as well as suggestions
for improvements. This feedback was obtained through a
survey administered at the end of the course and was a mix-
ture of quantitative feedback using a Likert scale, as well
as qualitative feedback through open-ended questions. Ad-
ditionally, student grades from previous semesters will be
used in comparison to the students in the 2012-2013 school
year to determine effectiveness of understanding.
4.1 Feedback from Students - Fall 2012
The quantitative feedback was elicited through twelve state-
ments. A Likert scale accompanied each question, using a
scale of 1-5, with a 1 meaning “Strongly Disagree” and a 5
meaning “Strongly Agree.” Twenty-one students completed
the survey. Table 1 represents the list of questions asked.
The students were asked five open-ended questions. The first
Table 1: Fall 2012 Quantitative Questions and Re-
sponse Averages
1 The lab was a valuable component to the 3.62
course.
2 The code reviews in the lab were helpful 3.43
to see other students’ solutions and ways
of thinking.
3 I found working with others in the lab a 4.1
valuable learning experience.
4 I was given adequate time to complete all 4.43
of my teammates’ code reviews.
5 I liked that each student was held account- 4.00
able for the amount of effort put into the
code reviews.
6 The labs reinforced concepts introduced 3.48
during class time.
7 The homework helped me to understand 3.76
concepts introduced in class.
8 I found the homework to be busy work. 3.38
9 The quizzes given were valuable to tell me 3.9
where I stood, in terms of understanding
concepts covered in class.
10 I would use the quizzes to study for the 4.48
exams.
11 I found the workload for this course to be 3.12
too much.
12 I liked that the exams were part written 3.48
and part practical.
of these questions was, “If I could change one thing about the
lab, what would it be? Why?” Responses included: having
more lab activities where students were divided into teams
to come up with a solution to a given problem; and having
the teams complete the program by the end of the lab, then
talking about unique solutions teams came up with during
the next class period. Specific suggestions were made to
change the code review to make everything electronic and
to make the review items more specific than the others’ “ran-
domly” circling responses.
The second question posed to the students asked, “A couple
of times during the course of the semester we had lab ac-
tivities where teams worked together to work on a problem,
instead of code reviews. Which do you prefer in the lab:
the activities or the code reviews? Why?” The respondents
sided with teamwork coding activities by a tally of 17-3 (two
students liked both). The reasons for the team coding ac-
tivities included students learn more with these activities,
because they mimic the real world by working with others
to solve a problem, plus everyone takes part in the project.
Students who were in favor of code reviews felt like they re-
ceived immediate feedback on what they had done, as well
as ideas on other ways to solve a problem.
The third open-ended question was, “If I could change one
thing about the homework assignments, what would it be?
Why?” Some students were in favor of no changes; others
were split over the randomness of when homework was due.
Those in favor of the randomness liked being kept on their
toes; those against it felt more pressure to get everything
done.
The fourth question asked was, “If I could change one thing
about the quizzes, what would it be? Why?” Eleven stu-
dents stated the quizzes were fine “as is”; students liked the
fact that the “quizzes (adequately) prepare you for exams.”
Others suggested the questions not be weighted so heavily.
The last question asked was, “If I could change one thing
about the exams, what would it be? Why?” The most pop-
ular response to this question was that the students needed
more time; two students suggested moving the exam time
to a lab time. Two students suggested removing the tracing
problem.
4.1.1 Discussion
Using the administered questionnaire and its results, some
of the suggestions made by the students were implemented
for Spring 2013. The first of these changes included ex-
panding the lab activities to alternate weeks between code
reviews and team coding activities. The students did seem
more engaged with the coding activities, based on instruc-
tor observations in the lab. The questionnaire confirmed
the students’ enthusiasm in the lab with working together
to solve a problem.
The other major change instituted for the Spring 2013 term
was that homework would be assigned at the end of every
class, as before, except that the homework was due at the
beginning of the next class period. This change, hopefully,
will encourage students to stay on their toes with respect to
practicing and understanding concepts learned during the
lecture. The only exception to the due date is when the
next class period falls on an exam day; then the homework
is due on the next lecture day that follows.
4.2 Student Feedback - Spring 2013 Semester
Quantitative and qualitative feedback again was elicited from
students at the end of the semester. The previous semester’s
questionnaire was reused, with two additional quantitative
questions that were included, to gauge students’ thoughts
on the coding activities added for this semester. Thirteen
students completed the survey; the results can be found in

Table 2: Spring 2013 Quantitative Questions and
Response Averages
1 The lab was a valuable component to the 3.62
course.
2 The code reviews in the lab were helpful 2.69
to see other students’ solutions and ways
of thinking.
3 I found working with others in the lab a 3.85
valuable learning experience.
4 I was given adequate time to complete all 4.62
of my teammates’ code reviews.
5 I found the coding activities in the lab chal- 4.08
lenging.
6 I found working in groups on coding activ- 3.77
ities helpful to learning course material.
7 I liked that each student was held account- 4.31
able for the amount of effort put into the
team activities.
8 The labs reinforced concepts introduced 3.85
during class time.
9 The homework helped me to understand 4.08
concepts introduced in class.
10 I found the homework to be busy work. 2.69
11 The quizzes given were valuable to tell me 4.23
where I stood, in terms of understanding
concepts covered in class.
12 I would use the quizzes to study for exams. 4.69
13 I found the workload for this course to be 2.85
too much.
14 I liked the fact that the exams were part 2.85
written and part practical.
Table 2. As with the previous semester, the students agreed
with the idea that they had adequate time to complete their
code reviews; liked the fact that each student was held ac-
countable for the amount of effort put into each lab activity;
the homework was a helpful aid; and they studied for exams
with the quizzes given in class. The students also agreed,
albeit not as strongly, that the lab is valuable to the course;
working with others is a valuable learning experience; and
the labs reinforced concepts from class. The students also
reaffirmed that the workload was not too much for them,
just like their Fall 2012 counterparts. Because we added the
group coding activities to the lab, Questions 5 and 6 were
new. Students found the coding activities challenging, yet
those exercises were helpful in learning course material.
The same five qualitative questions were posed to students
that were asked in the Fall 2012 semester. A variety of
responses addressed changing the lab. For example: one
positive comment said, “In general, it allowed for more con-
cepts to be openly discussed instead of reviewing the same
general project 3 or 4 times.” Another student appreciated
having more group programs than code reviews. A third
student said that “the code reviews ’wasted’ time that we
could have used to practice more problems.” Generally, more
group programming activities were suggested because code
reviews were not helpful.
With respect to the second question (code reviews v. code
activities), only two students favored code reviews; a third
student found both types of activities helpful. Reasons in
favor of code reviews included seeing how others came up
with their solutions, hearing suggestions on one’s own work,
or just seeing other solutions in general. Lab activities were
preferred for different reasons: they allowed general involve-
ment from everyone in the group; gave a further understand-
ing of concepts from class; enabled them to work as a team
to solve a problem; if a student wasn’t learning something
new about a section, it re-enforced current knowledge; and
helped students feel like they were learning something.
The third question posed to the students concerned chang-
ing the homework. Six students responded that they would
not change anything. Four responded that they would like
less homework assigned; one said that “homework on top
of the programming assignments is far too much.” While
one of these students was concerned about the volume, he
or she did state that the homework did help with under-
standing the material better. One student suggested not
having homework due on the same day as a programming
assignment. Remaining issues included having the professor
explain the homework beforehand because what the book
stated was unclear, as well as a dislike for being graded on
whether the homework submitted worked or not and a desire
for more feedback about what went wrong.
Responses to the fourth and fifth questions remained con-
sistent with student responses from Fall 2012.
4.2.1 Discussion
As with the administered questionnaire in the Fall, students
remain closer to agreeing than being neutral about benefits
of the lab. As with the responses to the Fall 2012 students,
these students responded more positively toward group cod-
ing activities over code reviews. The lab component is still in
its infancy, so using more group coding activities in Fall 2013
is probable, with even fewer code reviews. Code reviews,
however, should not be totally shelved. It is important to
see how others arrive at their solutions and emphasize there
is more than one way to get from start to finish.
The slight attitude change for homework is encouraging. As
evidenced from the Fall 2012 semester, students prefer struc-
ture over randomness concerning when homework assign-
ments are due. The purpose of the homework was mainly to
get the students to write code more frequently, beyond their
programming assignments, with the hope that this increase
in coding would result in a better understanding of material.
4.3 Comparing School Years 10-11 and 12-13
Table 3 shows the final letter grade students earned over
the course of the semester. This table includes students
who completed the course; it omits students with excessive
absences or those students who stopped showing up closer
to the end of the semester. The data suggest there might be
benefits from revamping the course because students appear
to be making higher grades. Student performance is shown
in Table 4. The figures show significant improvement in
exam averages and final exam averages with changes to the
course. Since changes have been made to exams and finals
themselves, numbers in Table 5 list correct percentage for
each of the common areas of the exams (short answer, short
coding, tracing, and long coding). As Table 5 notes, there
 students seem to find working in groups beneficial to their
Table 3: Final Grade Distribution - 10-11 and 12-13 understanding. They respond more positively to group cod-
Semester Students As Bs Cs Ds Fs
ing as opposed to the code reviews completed in groups.
Fall 2010 25 3 3 11 3 5
More group coding exercises may be introduced in future
Spring 2011 19 1 3 3 5 7 course offerings, but code reviews will not be completely
Fall 2012 24 4 4 6 5 5 eliminated from lab activities. The department feels that it
Spring 2013 17 5 1 5 4 2 remains important for students to see other ways of thinking
and understand there often is more than one way to reach a
solution.
Table 4: Performance - Exams and Assignments
Semester Exams Assignments Final Exam
Fall 2010 57.19 72.83 44.04
6. REFERENCES
[1] T. Beaubouef and J. Mason. Why the high attrition
Spring 2011 51.25 68.14 44.32
rate for computer science students: some thoughts and
Fall 2012 68.66 77.38 68.02 observations. ACM SIGCSE Bulletin, 37(2):103–106,
Spring 2013 68.76 70.65 64.68 June 2005.
[2] D. Brown. Cs 1 labs: goals and expectations. ACM
SIGCSE Bulletin, 24(4):29–34, December 1992.
are some improvements seen in performance on the common
[3] F. Ford, L. King, L. Kovijanic, A. Kumar, M. D.
areas of the exams. Tracing remains an issue to students.
LeBlanc, and L. Wilkens. The effectiveness of
The long coding segment is also lower, in spite of the fact
structured labs in cs1. Journal of Computing Sciences
that this portion of the exam is open-book, open-note. Part
in Colleges, 17(6):6–9, May 2002.
of the problem with these two areas may lie in the fact that
[4] C. Hundhausen, A. Agrawal, D. Fairbrother, and
students feel rushed for time when getting to these last two
M. Trevisan. Integrating pedagogical code reviews into
sections.
a cs 1 course: an empirical study. ACM SIGCSE
Bulletin, 41(1):291–295, March 2009.
5. CONCLUSIONS AND FUTURE WORK [5] P. Kinnunen and L. Malmi. Cs minors in a cs1 course.
Our department introduced the use of a lab to accompany In Proceedings of the Fourth International Workshop
our CS1 course as well as other changes to help students with on Computing Education Research, pages 79–90.
the course material. The lab consisted of students review- ACM, September 2008.
ing one another’s code in groups, as well as group coding [6] P. Lassere and C. Szostak. Effects of team-based
activities. The students critiqued each other’s impact on learning on a cs1 course. In Proceedings of the 16th
helpfulness and their active participation in a group setting. annual joint conference on Innovation and technology
Other changes included daily homework assignments, which in computer science education, pages 133–137. ACM,
were collected the following class period. Quizzes between June 2011.
exams were added as a diagnostic to show a student’s com- [7] N. LeJeune. Critical components for successful
prehension of topics. The exams also were altered to allow collaborative learning in cs1. Journal of Computing
students an opportunity to complete a traditional “long cod- Sciences in Colleges, 19(1):275–285, October 2003.
ing problem” in the form of a practical question. [8] R. McCauley, C. Starr, W. Pharr, R. Stalvey, and
G. Pothering. Is cs1 better with the same lecture and
The data on final grades, as well as exams, show some lab instructor. ACM SIGCSE Bulletin, 38(2):54–60,
improvement related to grades earned. Students still feel June 2006.
rushed for time when they must complete both a written
[9] N. H. Narayanan, C. Hundhausen, D. Hendrix, and
portion and the practical portion of exams. This rush for
M. Crosby. Transforming the cs classroom with
time may contribute to poor scores in the tracing and long
studio-based learning. In Proceedings of the 43rd ACM
coding components of exams. Perhaps some homework could
technical symposium on Computer Science Education,
be geared toward more frequent tracing practice between ex-
pages 165–166. ACM, March 2012.
ams as well.
[10] E. A. Patitsas and S. A. Wolfman. Effective closed
Another year of study is required to see what further changes labs in early cs courses: lessons from eight terms of
might be needed to maximize help provided to students so action research. In Proceedings of the 43rd ACM
that they can understand the material. The idea of mov- technical symposium on Computer Science Education,
ing exams to a lab period might be feasible, as long as all pages 637–642. ACM, March 2012.
students can show up for the same lab block. In our lab, [11] L.-K. Soh, A. Samal, S. Person, G. Nugent, and
J. Lang. Analyzing relationships between closed labs
and course activities in cs1. In Proceedings of the 10th
annual SIGCSE conference on Innovation and
Table 5: Exam Sections - Performance technology in computer science education, pages
Exams Short Short Tracing Long 183–187. ACM, June 2005.
Answer Coding Coding [12] G. N. Walker. Experimentation in the computer
Fall 2010 54.43% 61.56% 44.76% 55.97% programming lab. ACM SIGCSE Bulletin,
Spring 2011 61.85% 64.02% 41.07% 49.01% 36(4):69–72, December 2004.
Fall 2012 71.79% 67.11% 50.3% 63.34%
Spring 2013 74.48% 70.44% 55.88% 64.6%
Reproduced with permission of the copyright owner. Further reproduction prohibited without
permission.