Handling Heterogeneity in Programming Courses for
Freshmen
Dino Capovilla, Marc Berges, Andreas Mühling and Peter Hubwieser
TUM School of Education
Technische Universität München
Arcisstr. 21, 80333 München, Germany
Email: {dino.capovilla, berges, andreas.muehling, peter.hubwieser}@tum.de
Abstract—One of the biggest challenges of the computer-
science department at our university is handling the enormous
heterogeneity of freshmen concerning both their previous pro-
gramming abilities and their learning behaviors due to their
biographical and social background.
In this paper, we present the design and evaluation of a
preliminary programming course based on the teaching method
of Mastery Learning that is particularly suited for groups of
students characterized by considerable diversity. Trained peer
tutors closely guide the participants through a step-by-step
programming exercise. We tested the method in several courses
that ran for two and a half days four weeks before the start of
lectures. We collected data from two different surveys(N = 200
and N = 300, respectively).
First, we quantified the considerable differences concerning
the prior experience in programming of the participants. Second,
we succeeded to show that the outcome of our method is
independent from different sensory preferences and different
computer-usage behaviors of the students. Third, the results of
the survey demonstrate that our method is suited to increasing
the self-perception of programming ability. This helps freshmen
to overcome initial self-doubts when beginning their CS studies.
I. I NTRODUCTION
Beginning CS students arrive at university with a diverse
background in programming experiences. Also, their respective
social background further increases diversity e.g. concerning
their ability to adapt to a new way of learning when coming
from secondary schools into university. Handling this hetero-
geneity is one of the biggest challenges of the CS-department
at our university. This heterogeneity is, for example, due to
students’ specific prior experiences and approaches to learning
[1]. These can also be influenced by various disabilities. Due
to the implementation of the “UN Convention on the Rights of
Persons with Disabilities”, we expect the number of students
with disabilities to increase substantially in our courses, as
the UN-BRK [2] demands that universities must accommodate
people with disabilities as part of their regular study programs.
The research questions we are trying to answer in this
paper are twofold. First, we want to quantify the extent of
heterogeneity concerning several influencing factors. Second,
we want to find out, whether or not the method of Mastery
Learning can be successfully applied to alleviate the differ-
ences before the start of lectures.
The programming abilities of our freshmen range from
no experience at all to almost professional expertise. This
heterogeneity becomes especially relevant, since the students
IEEE,
c 2015. This is the author’s version of the work. It is posted here by permission of IEEE for your personal use.
Not for redistribution. The definitive version was published in 3rd International Conference on Learning and Teaching in
Computing and Engineering (LaTiCE), 2015.
http://dx.doi.org/10.1109/LaTiCE.2015.18
with no prior experience are forming the largest part of the
drop-outs in other studies: “Little or no pre-college exposure to
computer science programming” is given as the primary reason
for dropping out of CS studies [3]. Besides the differences in
programming experience, the expectations that students have of
computer science can vary enormously [4]. These are typically
formed by the students’ social background and can also result
in different ways of learning or approaching CS studies. This,
in turn, can lead to great differences in “problem understanding
and reflection about the problem and the solution” [5].
To support freshmen and prevent them from dropping out,
we offer special courses on a voluntary basis. These courses
last two and a half days and take place four weeks before the
start of the regular CS1 lectures. Here, we are focusing on
the students’ self-perception of their programming ability. The
methodology is based on the idea of Mastery Learning and
a very intensive support from peer tutors. These tutors were
instructed to guide the participants in small steps through a set
of programming assignments. The workbook mainly contained
reproducible examples and exercises and the project was split
into several small parts. Proceeding to the next assignment was
only allowed after mastering the current one.
In a study presented in this paper we measure the impact
and success of this approach. We investigated how the success
of our course depends on a student’s sensory preference and
computer-usage behavior and how it influences the (subjec-
tively judged) gain in knowledge and perceived success.
II. BACKGROUND AND C OURSE D ESIGN
A. Context and Situation
All students who enrolled for a major in CS were invited
by the CS department to take part in our course. Also, the
websites of the university informed potential freshmen about
the courses. Participants had to register online in order to
take part. During the registration, we asked them about their
prior programming experience. This was done by specifically
asking them how many lines the biggest program has that they
developed. They could choose between three levels: (L1) “I
have no experience at all”, (L2) “less than 100 lines of code”,
and (L3) “more than 100 lines of code”.
We formed groups based on this self-assessment in order to
prevent less experienced students from getting frustrated by the
speed of experienced participants in their groups - a problem
that has been noted for CS1 courses by e.g. [6]. Conversely,
more experienced students may then progress at a faster pace
in order to prevent them from getting bored. Each group had content into manageable units. The students process these units
about 11 participants. Table I shows the number of participants autonomously in a self-allocated time period. The learning
and the number of groups for each level in the years of 2012 success is examined by an instructor after each unit. If the
and 2013. student masters the unit, she proceeds with the following
TABLE I. N UMBER OF PARTICIPANTS FOR EACH LEVEL OF PRIOR
one. Otherwise, the instructor helps her by giving further
PROGRAMMING EXPERIENCE . T HE NUMBER OF GROUPS IS GIVEN IN explanations or suggesting additional exercises. In our case,
PARENTHESES . the units are presented in form of a workbook composed
Level 2012 2013
of theoretical parts, examples, exercises, and corresponding
L1 97 (10) 161 (15) solutions. We favored this approach over a “‘minimal input”
L2 46 (5) 80 (5) design, as it as been observed to be problematic - especially
L3 55 (6) 76 (6)
Σ 198 (21) 317 (26) for science education [14].

The heterogeneity regarding the prior programming expe-
rience is rather large, as our results show. The results of Table
I taken together with the results of a questionnaire (see next
section) are shown in Table II, both in absolute and in relative
terms.
TABLE II. S ELF - ASSESSMENT OF PRIOR PROGRAMMING EXPERIENCE :
R EG . = N UMBER OF REGISTRATIONS ; Q UEST. = Q UESTIONNAIRE
Level Reg. 2012 Reg. 2013 Quest. 2013
L1 97 (49%) 161 (51%) 93 (44%)
L2 46 (23%) 80 (25%) 51 (24%)
L3 55 (28%) 76 (24%) 68 (32%)
Σ 198 317 212
B. Mastery Learning
Several studies have shown that freshmen consider it very
difficult to learn how to program [7], [8], [9]. Since program-
ming requires practical training and application of theoretically
learned concepts (investigated more closely in [10]), it is to be
expected that inexperienced programmers are facing a greatly
increased workload at the beginning of their studies. Also,
the beginning of studies at university marks a breakpoint for
students as they’re coming from secondary schools that work
rather differently.
The primary purpose of our courses is not to increase the
actual programming abilities in order to make the group of
CS1 students more homogeneous. This is hardly possible in
two and a half days and we also don’t want to get ahead of the
CS1 course. Instead, the aim of the course is to increase the
self-perceived programming ability of all students independent
of their prior knowledge and their biographical and social
backgrounds. Particularly, inexperienced freshmen should be
motivated to learn programming hands-on right from the
beginning and (even more important) associate programming
with a positive experience.
To implement such a course, two prerequisites must be
met: First, the topics must be presentable in an individualized
manner in order to reach all students irrespective of their prior
knowledge and social background. At least within the bounds
of “beginning CS students”, so we can assume, e.g. that they
are able to read. Second, the course must be designed in a way
that gives every student the possibility of experiencing a sense
of achievement.
Our method is based on the theory of Bloom’s Mastery
Learning1 [13]. Mastery Learning works by dividing learning
1 There are different progressive educational approaches similar to Bloom’s.
The basic idea can be attributed to Washbourne [11]. Keller developed the
PSI Personal System of Instruction [12] at almost the same time as Bloom.
To successfully create a sense of achievement for the stu-
dents, the “achievement-related self-concept”, which is influ-
enced by the “affective entry characteristics” [15] are of major
importance. Bloom assumes that the learning outcome depends
up to one quarter on these affective entry characteristics.
Such characteristics are formed essentially by the judgments
of parents, teachers and peers [15]. It can be assumed that
programming is seen by many as some form of “talent” - or
may at least often be associated with intelligence. This would
explain that “not being able to program” is a typical reason
given by drop-outs.
As Dweck and Leggett show [16], learning outcomes are
heavily influenced by the subjectively perceived possibility
of changing one’s talents. They show that if learners believe
that intelligence (aptitude) is not malleable but fixed, their
perceived personal ability to solve an assignment will be
much lower than if they believe the opposite. This has also
been shown to influence beginning students in their choice in
favor or against a CS-major [6]. The self-perceived ability is
influenced essentially by the judgments of parents, teachers
and peers, too. This underlines the crucial role of teachers
because their comments and behavior will foster or obstruct
the students’ confidence in their aptitudes.
Our method of creating worksheets to present the necessary
background information to the students allows the aforemen-
tioned prerequisite of an individualized presentation that is
suited to each student’s needs - as long as they’re able to read
and write. Graphical representations can be supplemented by
textual descriptions for visually impaired persons, or - as in
our case - left out completely. By supplying the worksheets
in a digital form, all sorts of special input and output devices
can be used with them, accommodating the special needs of
students with (visual) impairments. By using simple speech
(or translating the worksheets into English) students from
foreign countries or deaf or hard of hearing people can be
accommodated.
In contrast to typical Mastery Learning approaches, we
greatly emphasized the role of the tutor and also reduced
the group size considerably. The tutor is needed to help the
students gain a sense of achievement and also to support those
learners, who are more oriented towards verbal communication
in their sensory preferences. As shown by Cottam et al.
[17], peer tutors are well suited for this task. They found in
their study of the effect of peer tutoring in CS1/2 significant
differences in the exam grades and consider peer tutoring
as an intervention to improve performance and retention in
computer-related courses.
C. Course Description
The courses that have been investigated in the study pre-
sented here have taken place between four and two week before
the start of regular lectures. There were four identical runs of
the course taking place in direct succession. Each course lasts
15 hours, split up into 5 sections of 3 hours each. The courses
took place in a computer lab at our faculty. The students
worked with Java and the NetBeans IDE and could also bring
their own laptop. Java and NetBeans was chosen because the
CS1 course that the students are attending afterwards are using
the same technology.
Based on several studies that describe the concept of
“arrays” to be very hard for novice programmers (e.g. [18],
[19]), we were looking for an assignment simple enough to
be understood within the short amount of time and involving
basic concepts of programming with particular attention placed
on arrays. We chose to have the students implement the board
game “Mastermind” as it fulfills these requirements.
In order to make this assignment suitable for Mastery
Learning, we split it into a basic version and two extensions
divided in several steps. This is the summary of the assignment
given:
Basic version:
1) Set a four digit number like 1453 or 9467. This
number is hard coded in the source code. The player
has to find out this number.
2) The player enters a four-digit number as a guess.
After each guess the computer responds with how
many of the guessed digits are contained in the
number and how many digits are already at the correct
position.
3) Step 2 will be repeated until the player guessed the
right number or a maximum of 12 repetitions has
been reached.
Extension level I:
1) The number should be chosen randomly by the com-
puter.
2) The length of the number should be set by the player
before the start of the game.
Extension level II:
1) The program should be amended such that the player
sets the number and the computer tries to guess it.
Repetitions should be displayed on the screen.
We used a special Java class, that simplifies the program-
ming by providing a simple (procedural) API that can be
used without going into the details of object-orientation2 . For
example, the class offers (static) methods like readInt(),
readString(), or write().
Of central importance is that the participants should all
directly experience a feeling of self-efficacy when taking their
first steps into programming. Depending on a student’s prior
experience, the peer tutors decide how much (and what kind
of) support they are offering. We hope that the feeling of
2 URL will only be included in final paper due to anonymity
having produced a working program alleviates the (sometimes
overwhelming) complexity of programming that beginners
often feel. Instead we want to achieve an increase in their per-
ceived programming abilities. If this is achieved, we hope that
“programming” is associated with a positive social experience
and the sense of an achievement.
The students were free to work individually or to collabo-
rate with other participants. In order to avoid that participants
may not be able to accomplish individually what their group
can [20], everyone had to develop an independent program.
They had to upload the source code on our server at lunch
break and at the end of every day. Finally, each participant
created up to five consecutive versions of his program. The
uploaded code was used to calculate the time needed to
complete the assignment. This was possible by subtracting the
start time from the time stamp of the last code package. We
only used an aggregated form of this data in the form of 0 to
6 hours, 6 to 9 hours, 9 to 12 hours and 12 hours and more.
The workbook is based on the textbook Java: How to pro-
gram [21]. It is composed of 13 pages and divided in 7 units.
The first four units contain a description of the assignment
to solve and the basic rules and concepts of programming in
Java. These four units are presented with many examples and
small exercises with solutions. Additionally, the students had
access to the internet. Unit 5 consists of writing an executable
program with some basic functionality. We considered the
achievement of this level as fulfilling the expectations. Unit
6 and unit 7 were considered as exceeding the expectations
and exceeding the expectations by far, respectively.
We offered the workbook in two languages (German and
English) and also offered access to a digital version besides the
printed one. As pointed out above, we explicitly left out graph-
ical representations and visualizations due to the problems
associated with visually impaired students. As visualizations
are a common teaching aid in computer science, it is not
hard to find it elsewhere, if desired. The peer tutors helped
the students to find such material online and in books.
Each group was supervised and guided by a peer tutor. As
tutors we employed experienced students that convinced us of
their CS-abilities as well as their soft skills. All these students
had already attended a regular 3-day preparation course for
student tutors in which they learned basics of education and
teaching methods. The tutors were given a written description
of our teaching method and their tasks together with a written
“code of conduct”. Additionally, they were briefed by us right
before the start of their courses. We stressed the important
aspects of their job again and answered any questions that
they had about their tasks. We advised the tutors to give
a brief introduction of the assignment, of the use of the
workbooks, and of the concept of Mastery Learning. Also,
they should stress right from the beginning the possibilities
of using the internet and additional literature. Above all, the
tutors should keep a close eye on the students with little prior
knowledge and on those with major difficulties. To locate these
students they used a report form of the individual progress
(only for themselves) and were asked to pay attention to their
interactions and behavior.
The forms simply collected, for each student, the units
of study that this person has successfully completed already.
The students had to report to their tutor whenever they had
finished a unit. Therefore, a lack of progress is directly
observable by the tutor in this form. In these cases the tutors
should specifically offer additional help to the students and
try to identify what problems they are currently facing. We
had a response rate of approximately 70% concerning theses
progress forms. We used them to evaluate the success of the
participants. We verified the validity of the data of the progress
forms by examining the code of 10 participants chosen at
random that has been uploaded.
III. DATA C OLLECTION
A. Questionnaire
In 2013, we collected personal data of the participants
by an online survey (using LimeSurvey3 ). Participation was
voluntary and anonymous. 212 of 250 participants left a
complete response that was also deemed “valid” by us, in the
sense that the responses were plausible.
The participants were asked for their gender, course of
studies, the self-assessment of their programming skills (L1-
L3, as described above), and the grade of their university
entrance qualification. Courses of study with less than 20
participants were aggregated as “miscellaneous”. Also, we ag-
gregated the grades of their entrance qualification into “high”
and “low” performer - excluding the middle ground in order
to get a clearer picture of the two extremes.
We also asked them about their computer-usage behavior.
The question was: “How much time of your total time spent at
a computer is allocated to the following: Playing games, Pro-
gramming, Using social media, and Other.” For each category,
the participants could chose on a 5 point scale ranging from 1
= (almost) no time to 5 = (almost) all the time. Each participant
that has given a value of 3 or above to exclusively one activity
was taken by us to “belong” to one of three categories formed
by these three options. The category “other” was only used to
prevent a bias by the participants towards our three activities,
but we disregarded all students belonging to this category.
Additionally, the students should assess their subjectively
perceived learning effect and sense of achievement. We asked
them to rate their general increase in knowledge, their increase
in programming abilities and their subjectively felt sense of
achievement again using a 5-point scale ranging from 1 =
nothing to 5 = very large.
Finally, the last section contained the 48 items of the
VARK learning style test. The VARK model is based upon
several sensory preferences regarding the reception of infor-
mation. Flemming and Mills[22] are distinguishing between
four different types: visual (V), aural (A), read/write (R), and
kinesthetic (K). A person can also have several preferences,
which are called multi-modal combinations between these
types. A person that is of learning type A prefers an acoustic
stimulation and is mostly learning from listening. Learning
types V in turn prefer a visual stimulation and are typically
very prone to visualizations. A special type of visually oriented
learners are those of type R - they need a visual stimulation but
preferably in the form of written text. Finally, kinesthetic or K
types are combining several channels for information reception
3 www.limesurvey.org
and are typically learning best by concrete experiences and
active experimentation. The learning type according to the
VARK model is tested by a series of questions that are
presenting real-world, everyday situations (e.g. “someone is
asking for directions, what would you prefer to do?”) and
providing four courses of action (e.g. “showing the way on
a map”) which are considered to correspond to one of the four
types. The responses to theses questions are then summed and
the maximal value among each of the four types is the type
of the person. If there is no clear maximum, i.e. if there are
several types with the same value, the person is considered to
be of a multi-modal type.
B. Exam results
We used the final grades that the students received after
their CS1 course for our survey as well. We grouped the exam
participants into four groups, three corresponding to the levels
of prior programming experience (L1 - L3) as assessed by
our survey and a fourth group for those students who did not
participate (NP) in our courses. The exam was split into two
parts - one theoretical and one practical. We evaluated these
two parts differently. In order to compare the results of the
single groups applying the Two-Sample Welch t-test [23] we
used the scores achieved in the exam instead of the actual
grades.
IV. R ESULTS
A. Course Performance
Regarding the time needed to complete the whole assign-
ment we formed four intervals, as described above. We had six
persons leaving the course prematurely. These were assigned
to the last interval. TableIII shows a cross-tabulation of the
prior experience and the amount of time needed to complete
the task.
TABLE III. T IME NEEDED TO COMPLETE THE TASK DEPENDENT ON
PRIOR PROGRAMMING EXPERIENCE . S HOWN ARE THE NUMBER OF
PARTICIPANTS IN EACH CATEGORY.
Level [0h..6h] ]6h..9h] ]9h..12h] ]12h..∞]
L1 0 0 6 54
L2 1 6 5 5
L3 5 6 14 16
Σ 6 12 25 75
The mean value of the time needed to complete the
assignment was more than 10 hours (about 700 minutes, with a
standard deviation of 171 minutes). All in all, the values ranged
from 336 to 911 minutes. Those students who completed
every unit (64 persons) have a mean value of 667 minutes
(sd = 166) work time. About 5% of the participants completed
the assignment within the first 6 hours (i.e. after the first day).
An additional 10% completed the assignment within the first
9 hours and another additional 21% finished after 12 hours
(i.e. after two days). The remaining 64% either made it within
the allocated 15 hours, did not complete the assignment or
dropped out.
Concerning the individual progress of the participants, we
examined the results of the progress forms filled out by the
tutors. This allowed us - in particular - to find out how many
of the participants reached the basic level as well as the two
additional levels of the course. Table IV shows the data both
in absolute and relative quantities.
TABLE IV. E XAMINATION OF THE PROGRESS FORMS . P = NUMBER OF TABLE V. R ESULTS OF THE GROUP COMPARISONS : KG = GAIN IN
PARTICIPANTS ; OK = EXPECTATIONS FULFILLED ; OK + = EXPECTATIONS KNOWLEDGE , AG = GAIN IN PROGRAMMING ABILITIES , SA = SENSE OF
EXCEEDED ; OK ++ = EXPECTATIONS FAR EXCEEDED . ACHIEVEMENT. F OR COURSES OF STUDY, BUSINESS ADMINISTRATION
(BA) WAS COMPARED TO COMPUTER SCIENCE (CS) AND GAMES
Level P ok ok+ ok++ ENGINEERING (GE). T HE COMPUTER USAGE BEHAVIORS ARE
2012 L1 76 72 (95%) 58 (76%) 23 (30%) SOCIAL - MEDIA (SM), PROGRAMMING (PR) AND PLAYING GAMES (PG). *
L2 25 25 (100%) 25 (100%) 19 (76%)
L3 52 49 (94%) 47 (90%) 37 (71%)
= p < 0.05; ** = p < 0.01; *** = p < 0.001
Σ 153 146 (95%) 130 (85%) 79 (52%)
Groups KG AG SA
2013 L1 102 91 (89%) 76 (74%) 36 (35%)
L2 - L3 3.6 < 2.8*** 3.6 > 2.4*** 4.0 > 3.7
L2 14 14 (100%) 13 (93%) 13 (93%)
L3 - L1 2.8 < 3.9*** 2.4 < 3.8*** 3.7 < 3.8
L3 21 21 (100%) 18 (86%) 15 (71%)
female - male 3.8 > 3.4* 3.7 > 3.2** 3.8 > 3.7
Σ 137 126 (92%) 117 (85%) 64 (47%)
BA - CS 3.9 > 3.2* 4.0 > 3.0*** 3.5 < 3.9
BA - GE 3.9 > 3.4 4.0 > 3.2* 3.5 < 4.0
SM - PR 3.6 > 3.0 3.5 > 2.6* 3.6 < 4.0
PG - SM 3.6 > 3.0 3.3 < 3.5 4.0 > 3.6*
B. Exam Results
Interestingly, our data shows that the participants of the
course show a significantly better result in their CS1 exam For the computer-usage, 69 of the 213 students were
at the end of the first semester when compared to the others. assigned to the pattern of playing games. 18 were assigned
However, this may be due many reasons beyond the effect of to programming and 67 to using social media. All the others
the course per se, so the results have to be treated with some were not assignable to any of the three types unambiguously.
caution. The data shows that the “‘non-programmers” - on average -
judge their gain in knowledge and their sense of achievement
More specifically, the CS1 exam consists of two separate as higher than the programmers.
parts, namely a practical and a theoretical one. We were able For the VARK learning types, we were able to assess a
to match the data of 160 participants of the practical part to single type of 110 of the 213 course participants. The others
their respective self-assessments at the beginning of our course. were multi-modal types and disregarded for analysis. Overall,
For the theoretical part we were able to match 156 students. we had 20% of the kinesthetic type, 10% of the read/write
When comparing the results to the group of students that did type, 9% of the aural type, and 4% of the visual type. However,
not take part in our courses (487 and 429, respectively) the there were no significant differences to be found between any
following shows: For the practical part, the course participants of these groups.
reached (on average) 84% of the available points, whereas the
non-participants reached 78%. The difference between means V. D ISCUSSION
is highly significant with p < 0.003. Interestingly, for the
theoretical part, there is no significant difference between the As expected, the heterogeneity concerning the prior pro-
groups - participants reached an average of 63% and non- gramming experience are considerable, as Table II shows.
participants reached 62% in the mean. Roughly half of the freshmen have no experience at all,
whereas about a fourth have already considerable prior pro-
gramming experience. The amount of time that the students
C. Comparison of Different Groups of Students took to complete the course assignment (Table III) as well as
their individual paths of progress (Table IV) both reflect this
In order to compare how well our course design works heterogeneity.
in the light of heterogeneity, we compared different groups
dependent on their prior programming experience and on their Some students were able to complete the assignment in less
computer-usage behaviors. Specifically, we compared the three than 6 hours while others were not finished after 15 hours.
levels of experience with each other, the gender, their course Also, there are relatively more students with prior program-
of study and the three categories of computer-usage. We took ming experience that reached the final level of exceeding our
the results of our questionnaire, i.e. the self-assessed gain expectations by far. Clearly, we cannot fully account for the
in programming knowledge and abilities and their sense of amount of help that the peer tutor has given each student
achievement, as described above. The results are shown in along the way to the final solution. An “over-eagerness” of
Table V. For better readability, only those comparisons that peer tutors in their helping younger students has been reported
show a significant difference in one of our tests are shown. before [20]. Nevertheless, it is reasonable to expect the prior
In other words, since the comparison between the groups L1 programming experience to reflect back onto the amount of
and L2 are not shown, there were no significant differences time needed and on the level that is reached by a student. Our
regarding any of the three items we investigated. data shows exactly this.
There were no differences found between the low- and It is interesting to note that the course participants are
high-performers (using the grade of their university entrance actually performing better in the practical part of their CS1
exam). We selected 41 as high- and 49 as low-performers. exam. Clearly, we cannot deduce anything from this fact per
se, but it may clearly show an artifact of having attended our
Concerning the course of study, we had 213 students of course. It might also be that our course (as it is voluntarily)
computer science, 61 students of games engineering, and 30 only attracts the eager and active students. However, in this
students of business administration. According to the results, case, we would also expect to see a difference in the theoretical
the students of business administration felt a significantly part of the exam. One possible explanation is that our course
higher gain in knowledge and abilities when compared to the attracts students that have a practical approach to programming
CS students. only.
 When considering the subjectively felt gain in knowledge
and abilities, we can see that particularly the students with no
or little prior programming experience see the most increase
(Table V). This is in accordance with literature. For example,
in [24] it is reported that Mastery Learning is showing the
highest impact for less apt students. In our case the prior
programming experience reflects this. As there has been no
significant difference between the two lower levels of prior
experience, it seems reasonable to merge these two groups in
subsequent runs of this course.
The significant difference that was identified between fe-
males and males is explained by their respective prior pro-
gramming experience: Only 6% of all female participants have
chosen the highest level of prior experience, wheres 45% of
the male students have chosen this level. This may also explain
the difference between the students of business administration
and computer science, since it can be expected that the non-
CS students will, on average, have less prior programming
experience than the CS students. The same holds for the
computer-usage behaviors. Those students who fall into the
programming category will most probably also have more prior
programming experience, on average.
As there are no significant differences for the several
types of sensory preference, we can conclude that the single
most influencing factor on the perceived gain in knowledge
and ability is the prior programming experience. Whenever a
significant difference has been found, the groups that have been
compared will most probably reflect this difference in prior
experience (e.g. gender). All groups that will most probably not
reflect this difference (e.g. visually oriented learning type) are
not showing a significant difference concerning the perceived
knowledge gain.
So, future versions of this course should best focus even
more on the prior programming experience, for example in
the form of different assignments. It is positive to note that
the perceived sense of achievement has been rated consistently
high over all participants. As this has been the main goal of
the course, we see our design as successful.
VI. C ONCLUSION
Coming back to the research questions in the introduction,
we can state that a considerable amount of heterogeneity arises
from prior programming experience, differing computer usage
behaviors, and learning styles. Clearly, this list is not exhaus-
tive. However, as our data show, the single most influencing
factor seems to be their prior programming experience, which
is valuable information for subsequent changes of the course
design.
Concerning the second research question, we have pre-
sented the design of a course based on Mastery Learning that
was used in order to alleviate the difficult start of CS studies
at our faculty. The difficulty arises from several facts, among
them, the heterogeneity concerning their prior knowledge and
abilities in programming. Instead of focusing on particular top-
ics that the students should learn, our course placed emphasis
on conveying a sense of self-efficacy and achievement. We
hoped that this serves as a motivation in the first weeks of
their regular CS1 course and therefore decreases the effect of
a lack of prior programming experience. Clearly, the course
design is reflecting the very specific constraints of offering a
time limited short course right between the students secondary
school life and their new life at university. Nevertheless, our
results show that the design works well over range of factors
of diversity, like the sensory preference of the students.
R EFERENCES
[1] D. Capovilla, J. Krugel, and P. Hubwieser, “Teaching algorithmic think-
ing using haptic models for visually impaired students,” in Learning and
Teaching in Computing and Engineering (LaTiCE), 2013. IEEE, 2013,
pp. 167–171.
[2] UN General Assembly, “Convention on the rights of persons
with disabilities: resolution / adopted by the general assem-
bly,” 2007, a/RES/61/106, www.unhcr.org/refworld/docid/45f973632.
html (03.10.14).
[3] M. Biggers, A. Brauer, and T. Yilmaz, “Student perceptions of computer
science: a retention study comparing graduating seniors with cs leavers,”
in SIGCSE Bull., vol. 40(1). New York, USA: ACM, 2008, pp. 402–
406.
[4] M. Knobelsdorf and C. Schulte, “Computer science in context: path-
ways to computer science,” in Proceedings of the Seventh Baltic Sea
Conference on Computing Education Research, ser. Koli Calling ’07,
vol. 88. Darlinghurst, Australia: Australian Computer Society, Inc.,
2007, pp. 65–76.
[5] A. J. Gomes, A. N. Santos, and A. J. Mendes, “A study on students’
behaviours and attitudes towards learning to program,” in Proc. 17th
ACM Annu. Conf. Innovation and Technology in Computer Science
Education, ser. ITiCSE ’12. New York: ACM, 2012, pp. 132–137.
[6] C. M. Lewis, K. Yasuhara, and R. E. Anderson, “Deciding to major
in computer science: A grounded theory of students’ self-assessment
of ability,” in Proceedings of the Seventh International Workshop on
Computing Education Research, Rhode Island, USA, 8-9 August 2011,
K. Sanders, M. E. Caspersen, and A. Clear, Eds. New York: ACM,
2011, pp. 3–10.
[7] J. Bennedsen and M. E. Caspersen, “Failure rates in introductory
programming,” SIGCSE Bull, vol. 39, no. 2, pp. 32–36, 2007.
[8] S. Bergin and R. Reilly, “The influence of motivation and comfort-
level on learning to program,” in Proceedings of the 17th Workshop of
the Psychology of Programming Interest Group - PPIG’05, 2005, pp.
293–304.
[9] A. Robins, J. Rountree, and N. Rountree, “Learning and teaching
programming: A review and discussion,” Journal of Computer Science
Education, vol. 13 no. 2, pp. 137–172, 2003.
[10] M. Berges, A. Mühling, and P. Hubwieser, “The gap between knowledge
and ability,” in Proceedings of the 12th Koli Calling International
Conference on Computing Education Research - Koli Calling ’12.
ACM Press, 2012, pp. 126–134.
[11] C. Washbourne, “Educational measurement as a key to individualizing
instruction and promotion.” Journal of Educational Research, vol. 5,
pp. 195–206, 1922.
[12] F. S. Keller, “Good-bye, teacher,” Journal of Applied Behavior Analysis,
vol. 1, no. 1, pp. 79–89, 1968.
[13] B. S. Bloom, “Reasoning about naming systems,” Evaluation Comment,
vol. 1, no. 2, pp. 1–5, 1968.
[14] P. A. Kirschner, J. Sweller, and R. E. Clark, “Why minimal guidance
during instruction does not work: An analysis of the failure of con-
structivist, discovery, problem-based, experiential, and inquiry-based
teaching,” Educational Psychologist, vol. 41, no. 2, pp. 75–86, 2006.
[15] B. S. Bloom, Human characteristics and school learning. New York:
McGraw-Hill, 1976.
[16] C. S. Dweck and E. L. Leggett, “A social-cognitive approach to
motivation and personality,” Psychological Records, vol. 95, pp. 256–
273, 1988.
[17] J. A. Cottam, S. Menzel, and J. Greenblatt, “Tutoring for retention,”
in Proceedings of the 42nd ACM technical symposium on Computer
science education, ser. SIGCSE ’11. New York and NY and USA:
ACM, 2011, pp. 213–218.
[18] A. Ehlert and C. Schulte, “Empirical comparison of objects-first
and objects-later,” in Proceedings of the fifth international workshop
on Computing education research workshop, ser. ICER ’09. New
York, NY, USA: ACM, 2009, pp. 15–26. [Online]. Available:
http://doi.acm.org/10.1145/1584322.1584326
[19] S. A. Hansen, “Analyzing programming projects,” SIGCSE Bull.,
vol. 41, no. 1, pp. 377–381, Mar. 2009. [Online]. Available:
http://doi.acm.org/10.1145/1539024.1508999
[20] J. Carter, D. Bouvier, R. Cardell-Oliver, M. Hamilton, S. Kurkovsky,
S. Markham, O. W. McClung, R. McDermott, C. Riedesel, J. Shi, and
S. White, “Motivating all our students?” in Proceedings of the 16th
annual conference reports on Innovation and technology in computer
science education - working group reports, ser. ITiCSE-WGR ’11. New
York and NY and USA: ACM, 2011, pp. 1–18.
[21] P. J. Deitel and H. M. Deitel, Java: How to program, 9th ed. Upper
Saddle River and N.J: Prentice Hall, 2012.
[22] N. D. Fleming and C. Mills, “Not another inventory, rather a catalyst
for reflection,” To Improve the Academy, vol. 11, 1992.
[23] Student, “The probable error of a mean,” Biometrika, vol. 6(1), pp.
1–25, 1908.
[24] C.-L. C. Kulik, J. A. Kulik, and R. L. Bangert-Drowns, “Effectiveness
of mastery learning programs: A meta-analysis,” Review of Educational
Research, vol. 60 no. 2, pp. 265–299, 1990.