To all ICT faculty:
This past semester (Fall 2014) I taught 3 sections of IPC144 with a combined
total of 87 students.
By the end of the semester only 42 passed (representing a success rate of 48.27%).
Pretty abysmal results in spite of the fact that only 53 students wrote the final exam!
So, after yet another disappointing semester with respect to the overall success
rate of my first semester IPC144 students, I decided to review the results of
all of my previous programming students (going back to 1999) in an effort to
determine if this semester was an anomally or if it was more indicative of
an endemic problem, and if so, to better understand why.
With the exception of sections of DSA555 (Data Structures and Algorithms) where
student success rates were at or above 80% -and more significantly- the
introductory course BIF702 (Concepts of Programming I Using C) where student
success rate averaged close to 84%, the success rate of almost all of the
programming courses I taught hovered at or around the 50% to 60% range.
On occasion, students in some sections approached or exceeded 70%, while others were less than 50%.
Certainly, no introductory sections have ever approached or met the 80% success
rate recently mandated by our college.
So, while there have been exceptions, the low success rate (at least for me) has
continued to be an endemic problem.
Listed below is a breakdown of all 1st semester introductory courses I have delivered
during my time at Seneca College (from 1999 to current).
CPA/CPD 1st Semester IPC144 Student Success Rates (detailed) from 1999 to 2014
Year/Semester: Section: Students: Pass: Fail: Success Rate: A+: A: B: C: D: F:
1999.2 IPC144G 20 12 8 60.00% 3 5 1 1 2 8
1999.2 IPC144F 22 14 8 63.64% 1 3 5 3 2 8
1999.3 IPC144L 31 19 12 61.29% 5 4 5 5 0 12
1999.3 IPC144M 30 26 4 86.67% 5 6 10 5 0 4
2002.3 IPC144A 29 14 15 48.28% 3 3 1 5 2 15
2002.3 IPC144B 33 19 14 57.58% 1 8 1 8 1 14
2003.3 IPC144A 26 13 13 50.00% 3 3 6 1 0 13
2004.1 IPC144E 32 17 15 53.12% 4 5 6 2 0 15
2004.3 IPC144B 29 23 6 79.31% 4 8 7 3 1 6
2006.3 IPC144A 23 10 13 43.48% 5 2 0 3 0 13
2006.3 IPC144B 26 12 14 46.15% 6 3 1 1 1 14
2007.3 IPC144E 21 15 6 71.42% 5 4 4 1 1 6
2009.3 IPC144B 20 11 9 55.00% 6 3 1 1 0 9
2010.1 IPC144C 28 15 13 53.57% 6 4 2 3 0 13
2010.1 IPC144D 25 14 11 56.00% 3 4 5 2 0 11
2010.1 IPC144E 14 7 7 50.00% 2 3 2 0 0 7
2012.3 IPC144B 27 13 14 48.15% 5 2 4 2 0 14
2014.3 IPC144K 26 13 13 50.00% 3 5 4 1 0 13
2014.3 IPC144L 31 17 14 54.84% 6 8 3 0 0 14
2014.3 IPC144M 30 12 18 40.00% 1 8 3 0 0 18
AVERAGE: 56.42%
SBSAC 1st Semester BIF702 (BioInformatics) Student Success Rates (detailed) from 2004 to 2011
Year/Semester: Section: Students: Pass: Fail: Success Rate: A+: A: B: C: D: F:
2004.3 BIF702AA 19 14 5 73.68% 8 4 1 0 0 4
2005.3 BIF702AA 16 15 1 93.75% 8 3 4 0 0 1
2007.3 BIF702AA 14 12 2 85.71% 4 5 1 2 0 2
2008.3 BIF702AA 19 16 3 84.21% 2 6 4 3 1 3
2009.3 BIF702AA 14 11 3 78.57% 2 4 3 2 0 2
2010.3 BIF702AA 14 13 1 92.86% 3 3 4 1 2 1
2011.3 BIF702AA 14 11 3 78.57% 4 5 2 0 0 3
AVERAGE: 83.91%
The 2 courses (IPC144 and BIF702) are both introductory programming courses that
teach programming fundamentals using the C language. Other than the nature of the content
of examples and assignments used in class, the curriculum (including method of evaluation)
for both courses is identical. The differences are as follows:
Designation: Student: Avg. Class Size: Hours of Instruction:
IPC144 Diploma High School 27 4 (4 Lecture or 2 Lecture 2 Lab)
BIF702 Post-Diploma University 16 6 (4 Lecture 2 Lab)
The typical student in IPC144 is a high school graduate, has no programming experience
and is (on average) 18 or 19 years old. The typical BIF702 student, on the other hand,
is a university or college graduate typically holding a life-science degree or equivalent,
has no programming experience, and is (on average) 22 or 23 years old.
It is interesting to note that both sets of students typically had little or no
previous programming experience and nothing about either course (IPC144 or BIF702)
differed much at all, and yet BIF702 students significantly outperformed their IPC144
counterparts year after year.
In fact, if anything, in-class examples, assignments, and complexity of test questions were
often more rigorous in BIF702 vs those in IPC144!
I then decided to revisit a research paper written in 2001 by Tony Jenkins of
the University of Leeds (U.K.) entitled:
"On the Difficulty of Learning to Program" that I had initially read in the fall of 2014.
After reading through the paper a number of times, many of the observations made
by the author inspired me to review other related areas of interest. One of these areas
included the cognitive and biological basis of learning and memory
(some of which I was already familiar with). During my research and upon
reflection of my own personal teaching experience and observations, a number of
ideas and patterns began to emerge which I thought I would share with my
colleagues at Seneca.
As well, my research led me to learn more about all of the following:
1. The programming curricula of other colleges in the GTA and if/how they
differed from comparable offerings at Seneca,
2. Ontario high school curricula and prerequisites,
3. Reports from the Ontario ministry of Education and
the Education Quality and Accountability Office (EQAO), and
4. An overview of the cellular and biological basis of learning
and memory, among others.
Before I present my findings and recommendations, I thought I would
summarize many of the key points, observations, and recommendations presented
in the paper that served as my inspiration to further my research into
this matter.
===BEGIN
On the Difficulty of Learning to Program (2001)
Tony Jenkins
School of Computing
University of Leeds, Leeds U.K.
tony@comp.leeds.ac.uk
http://www.comp.leeds.ac.uk/tony
Abstract:
+ Few students find learning to program easy.
+ If computing educators are ever to truly develop a learning environment where
all students learn to program quickly and well, it is vital that an
understanding of the difficulties and complexities faced by students is
developed.
+ At the moment the way in which programming is taught and learned is
fundamentally broken.
1) Introduction:
+ Few computing educators of any experience would argue that students find
learning to program easy.
+ There is little evidence to suggest that visual "hooks" or attempting to
teach students to program through the medium of a game has any impact on
a student's ability to learn how to program.
+ If students struggle to learn something, it follows that this "thing" is
for some reason difficult to learn. Thus, if educators hope to teach computer
programming effectively, they must understand precisely what it is that
makes learning to program so very difficult for so very many students.
2) The Question of Aptitude:
+ Some educators argue that there is nothing inherently difficult about
learning to program and that the problem is simply that students do not have
an aptitude for programming. The skills often cited by many educators that
students lack are problem solving and mathematical ability, yet evidence for
the existence of aptitude in this sense is inconclusive at best.
+ Studies have shown that it helped if students had some experience with programming
prior to enrolling in a programming course (*1).
+ If aptitude then is not a causitive factor in understanding why students
find it so difficult to learn how to program, then a more cognitive view of
the learning process must be explored.
3. Cognitive Factors:
+ Two factors that present themselves as possibilities that might make learning to
program difficult are learning style and motivation.
3.1) Learning Styles:
+ Students will tend to adopt the learning style they prefer or which has served
them best in the past and therefore it is a crucial responsibility of the teacher
to ensure that the students adopt the most appropriate learning approach for
the subject at hand.
+ The best-known classification of learning styles divides learning into "deep"
and "surface" approaches. Deep learners concentrate on gaining an understanding
of a topic, while surface learners concentrate on little more than memorizing.
+ Programming is not a body of knowledge however, it is a skill.
+ Surface learning can be useful for remembering the details of syntax, or
issues such as operator precedence, but elements of deep learning
(and hence understanding) are required if a true competence is to be developed.
+ This is the key to the difference. The two learning styles must be applied
at the same time. It is not sensible to memorize the rules of the syntax of
some programming language and then to move on to apply it. This puts programming
beyond the educational experience of most students; it requires a mixture of
learning styles that most, if not all, of them have not had to apply before.
+ In this regard, learning to program requires a unique approach and
therefore presents students with a novel learning paradigm.
3.2) Motivation:
+ Some students have a genuine interest in the subject (an intrinsic motivation);
while others may see their degree as little more than a means towards a lucrative
career (extrinsic motivation); others may simply be trying to please their
parents or family (social motivation) (*2).
+ The form of motivation does appear to be a factor. It has been shown,
perhaps not surprisingly, that students who struggle in programming are more
likely to have a primarily extrinsic motivation than their colleagues who excel.
+ Perhaps the root of the problem lies in the subject. Is there something inherent
in programming that makes it especially difficult to learn?
4.) The Difficulty of Programming:
+ An experienced programmer draws on many skills and much experience. Some
of the required skills are obvious; problem solving ability and some idea of
the mathematics underlying the process are essential. A programmer must also
be able to use the computer effectively, must be able to create the program
in a file, compile it, and determine the output etc., but there are less obvious skills.
Adapting to a new environment and method of learning represents a period of
"transition" that is difficult for many new students. Yet, in the midst of
this they will be encountering some of the most basic material in their programming
course that is going to form the basis of the rest of their learning and will be
lost if they cannot keep up.
Learning to program is difficult enough to master when a student is well settled,
but departments' insistence on teaching this during a period of transition
can only increase the difficulty.
4.1) Multiple Skills:
+ Programming, then, is not a single skill. It is also not a simple set of
skills; the skills form a hierarchy. A student faced with learning a hierarchy
of skills will generally learn the lower level skills first, and will then
progress upwards. In the case of coding (one small part of the skill of
programming) this implies that students will learn the basics of syntax
first and then gradually move on to semantics, structure, and finally style.
+ An approach to learning that reinforces lectures that concentrate on the
minutiae of syntax, and by textbooks that adopt much the same approach
leads the student to hope to gain an understanding of programming by reading a
textbook. Programming is learned by programming, not from books.
4.2) Multiple Processes:
+ Programming is not only more than a single skill; it also involves more
than one distinct process. At the simplest level the specification must be
translated into an algorithm, which is then translated into program code.
In experienced programmers it is also possible to identify an intermediate
process whereby the algorithm is mapped to something resembling a "recipe"
for the program, based on previous experience.
+ The most difficult part of the process is the first, translating the
specification into the algorithm. This is also the most important, as
it is crucial that a correct and efficient algorithm is used as the basis
of any coding. Given a correct algorithm the other processes are essentially
mechanical.
+ Therefore, a student must master three distinct processes, but if
teaching concentrates on the low level issues of syntax at the expense
of the higher level, more complex, process of designing an algorithm, then
little or no learning will occur.
+ There is therefore little point in lecturing students on syntax when
they have no idea of where and how to apply it.
+ Teachers will be familiar with students who can follow the lectures in the
programming course, who can dissect and understand programs, but who are
totally incapable of writing their own program
(i.e. They have not mastered all the processes; they can code, but they cannot
produce an algorithm) (*3).
4.3) The Language:
+ There is scant solid evidence that any language is any better or any worse
than any other, and the choice continues to be driven largely by the
"flavour of the month" in industry.
+ Most teachers would agree that the purpose of an introductory programming
course is to teach the students to program; the intention is not to, for example,
"teach them Java".
+ Many languages used for teaching were not designed for teaching.
There exist languages designed for teaching (Pascal, LOGO), but any department
using one of these today would be an object of ridicule. Many would
worry about the effect on recruitment of not teaching a language that
was used in industry.
+ Languages designed for serious use by serious programmers are hardly
suitable for the novice. As a trivial example, consider the everyday
notion of "or", which also has a meaning in programming. A novice
programmer faced with the task of programming a conditional statement:
"if the answer is y or n" will be familiar with the everyday linguistic
meaning of "or", and may well code (in C):
if (answer == 'y' || 'n')
This makes perfect sense, especially when read aloud, but is clearly
semantic nonsense. Worse, this will compile and appear to work in some cases!
+ Thus, the The language used for teaching should be designed for that purpose.
4.4) Educational Novelty:
+ In his classic article on teaching programming (which should be required
reading for all who teach programming) Dijkstra argues that learning is a
slow and gradual process of transforming the "novel into the familiar".
He goes on to suggest that programming is what he terms a "radical novelty"
in which this comfortable tried and tested learning system no longer works.
The crux of the problem is, according to Dijkstra, that radical novelties
are so "disturbing" that "they tend to be suppressed or ignored to the extent
that even the possibility of their existence ... is more often denied than
admitted" (*4).
+ A particular feature of programming (and one that reinforces Dijkstra's message)
is that it is "problem-solving intensive" it requires a significant amount
of effort in several skill areas for often a very modest return.
At the same time it is "precision intensive" the modest success that
can be achieved by a novice programmer requires a very high level of precision,
and certainly a much higher level than most other academic subjects. Dijkstra
also notes that the "smallest possible perturbation" in a program of one single
bit can render a program totally worthless. This is precision indeed.
+ For students arriving in a setting where they are confronted with a totally
new topic that does not respond to their habitual study approaches, and where
a single semi-colon is the difference between glorious success and ignominious
failure, must surely represent a "radical novelty" in Dijkstra's terms.
It is perhaps not study skills that are needed, but coping skills!
4.5) Interest:
+ Learning (or perhaps here "being taught") programming can be very dull.
Lectures covering the details of syntax are never going to be especially
inspiring, and exercises that involve simple mathematical manipulations of
collections of student marks, stock levels, baseball statistics, or bank account
details are never going to set the pulse racing. Yet a glance in many
programming texts will yield many turgid examples of each of these.
+ At its best programming can be an enjoyable, creative activity, and many
students derive great enjoyment from their programming. They enjoy it
even more (and learn more) when they are allowed to work on assignments
that inspire them (*5).
+ It is a shame that so few assignments do indeed inspire.
4.6) Reputation and Image:
+ Programming courses acquire the reputation of being difficult. This
view is passed to the new students by their predecessors, and is
exaggerated in the telling. This perhaps makes it acceptable, even expected,
that a student will struggle.
+ At the same time, there is the public image of a "programmer". This is of
a socially inadequate "nerd", spending all hours producing arcane and
unintelligible code, fuelled by pizza and caffeine. It is hard to imagine
students aspiring to this image.
+ If students approach a course with an expectation that it will be difficult,
and with a negative image of those who excel in the subject, it is very hard to
imagine their being especially motivated. And students who are not motivated will
not succeed.
4.7) Pace:
+ Regardless of the duration of the the programming course, at the end there is
an assumption that the students who pass will be "able to program".
Students who miss or do not understand a basic concept and who then cannot
follow the next lecture may quickly come to the view that
"they just can't do programming" (the educationalists call this learned helplessness),
and will attribute this to the perceived difficulty of the subject.
+ The pace of the course is often driven mostly, of course, by the needs of
assessment. This scheme may be reasonable for many subjects, but it is
quite ridiculous for learning a skill such as programming.
5.) Conclusions:
+ Programming is certainly a complicated skill to master, and learning to program is
correspondingly complex. There are many features of the skill that contribute to
this complexity, and this paper has described some of the more important.
+ Some of these issues centre on the nature of the programming skill, while others
have more to do with the ways in which the participants teach and learn.
It must be possible to overcome these obstacles.
+ I talk to many students about their programming course. The most common comment
is that programming is "boring and difficult". When I ask whether it is boring
because it is difficult or difficult because it is boring, they are seldom sure.
But they remain adamant that it is both.
+ Teaching a subject that is boring and difficult is a tricky task indeed. The
essential problem is that programming represents an "educational novelty".
It represents this for those who teach as much as for those who learn.
It is clear that the students' tried and tested learning styles do not work
when applied to programming. It is equally obvious that the teachers' tried
and tested teaching fair little better.
+ So, why teach programming in this way? Presumably because that is the way
it's always been done. If this no longer works, something will have to change.
+ Learning to program is indeed difficult, but it should not be as difficult
as it currently appears.
Recommendations from the author:
1. Programming should never be taught before the second year of any course.
2. The language used should be chosen for pedagogic suitability and not
because it is popular in industry.
3. Programming should be taught by those who can teach programming and not
those who can program.
4. Programming courses should be designed to be flexible to allow different
students to learn in different ways.
5. There should be no summative (continuous) assessment to ease pressure on
students.
6. Departments should acknowledge that programming is difficult and supply
adequate support to students.
===END
At various points throughout the paper, I placed markers (*n) on ideas or
observations that gave me pause to think and led me to further investigate
each point separately (please see below).
(*1) Previous Programmming Experience:
At various times throughout the semester (but typically at the start), I engage
students by asking them questions and eliciting feedback.
One of the questions I routinely ask is if they have any previous programming
experience and take note of this for each stuudent.
So, I decided to review the results for all 3 sections of IPC144 this past
semester. These are the results I uncovered:
IPC144K
Student: Grade: Previous Programming Experience:
y*** A+ (high school)
bdaco**** A (high school)
nr**** A (high school)
thar**** A (high school)
dkh**** B (high school)
pj*** A (university China)
ljia**** A+ (university China)
kk**** D (unknown)
hl**** B (none)
dtmar**** B (high school)
mshu**** B (none)
jr**** A (unknown)
hz*** A+ (university China)
Total Students (IPC144K): 26
Total Passed: 13
Students who wrote the final exam: 15
Percentage of students who wrote the final exam (IPC144K) and passed: 13/15 = 86.67%
Percentage of students who passed having previous experience: 9/13 = 69.23%
IPC144L
Student: Grade: Previous Programming Experience:
kbarbo**** A (high school)
dtbre**** A (high school)
abug**** A+ (university Ukraine)
ssdh**** B (none)
mfdon**** A (high school)
teeng**** A (high school)
npkr**** A (high school/self taught)
gkry**** A (high school)
rlemedemo**** A+ (univeristy Brazil)
sme**** B+ (unknown)
sp**** A+ (high school)
bph**** D (unknown)
gapizzac**** A+ (high school)
jroytg**** A+ (high school)
oscha**** A (high school)
jrthom**** A (high school)
m*** A+ (high school)
Total Students (IPC144L): 31
Total Passed: 17
Students who wrote the final exam: 24
Percentage of students who wrote the final exam (IPC144L) and passed: 17/24 = 70.83%
Percentage of students who passed having previous experience: 14/17 = 82.35%
IPC144M
Student: Grade: Previous Programming Experience:
m**** B- (unknown)
ab**** A+ (high school)
rdu**** A (high school)
d**** B (high school)
ej**** A (high school)
skana**** A (none, mature student)
ej**** A (father/brother are programmers, taught student)
jli**** A (uncle is programmer, taught student)
ca*** A (high school)
gsin**** A (university India)
tv**** A (high school)
jzeva**** B (high school Brazil)
Total Students (IPC144M): 30
Total Passed: 12
Students who wrote the final exam: 14
Percentage of students who wrote the final exam (IPC144M) and passed: 12/14 = 85.71%
Percentage of students who passed having previous experience: 10/12 = 83.33%
Percentage of ALL students who wrote the final exam (IPC144KLM) and passed: 42/53 = 79.24%
*1) Percentage of ALL students with passing grades having previous programming experience: 35/42 = 83.33%*
* (number could be higher if students with "unknown" status have previous experience)
So, from these limited results, there was a strong correlation of those who had
previous programming experience and overall success in the course.
This led me to further investigate the Ontario high school curriculum to determine
where students may be receiving their programming instruction and their exposure to
computer fundamentals.
I discovered that the province has 2 mathematics streams;
one for university preparedness referred to as "academic", and another
for college prepartion referred to as "applied". Streams are listed below:
Ontario High School Mathematics Streams (Academic):
Grade: Course: Title: Stream:
9 MPM1D Principles of Mathematics Academic
10 MPM2D Principles of Mathematics Academic
11 MCR3U Functions Academic
|
12---> MDM4U Mathematics of Data Management Academic
|
12---> MHF4U Advanced Functions Academic
|
|
MCV4U Calculus and Vectors Academic
Ontario High School Mathematics Streams (Applied):
Grade: Course: Title: Stream:
9 MFM1P Foundations of Mathematics Applied
10 MFM2P Foundations of Mathematics Applied
11 MCM3F Functions and Applications Applied
12 MCT4C Math for College Technology Applied
An overview of the curricula of these mathematics courses reveals that
there are significant differences in the types of post secondary programs
that these mathematics streams are designed to prepare students for, and
from an overview of the course curriculum, it appears that one specific course within
the "academic" math stream (MHF4U) would be a more appropriate prerequisite
for eligibility to enroll in our computer programming and analysis (CPA/CPD) program.
From the Ontario ministry of education's grade 11/12 math overview (Academic):
"The Grade 11 university preparation course, Functions, builds on the concepts and
skills developed in the Grade 9 and 10 academic mathematics courses. The course
is designed to prepare students for Grade 12 mathematics courses that lead to
one of many university programs, including science, engineering, social sciences,
liberal arts, and education."
From the Ontario ministry of education's grade 11/12 math overview (Applied):
"The Grade 12 college preparation course Foundations for College Mathematics
satisfies the mathematical prerequisites for many college programs, including
programs in business, human services, hospitality and tourism, and some of
the health sciences."
I found that the applied (college) overview did not make mention of
any technology or science programs, yet after looking through the curriculum,
I did not discover where some students were obtaining their computer
programming experience.
I did however find references to a "Technology Education" stream that is
offered in some high schools and offer the following courses:
Grade: Course Code: Title:
11 TEJ3M Computer Engineering Technology University/College
12 TEJ4M Computer Engineering Technology University/College
From the Ontario ministry of education's grade 11/12 technology
education overview:
Grade 12 TEJ4M Computer Engineering Technology
"This course extends students understanding of computer systems and computer
interfacing with external devices. Students will assemble computer systems
by installing and configuring appropriate hardware and software, and will
learn more about fundamental concepts of electronics, robotics, programming,
and networks. Students will examine related environmental and societal issues,
and will explore postsecondary pathways leading to careers in computer technology."
This led me to further investigate the overall performance of students in both streams
and according to recent reports from the Education Quality and
Accountablity Office (or EQAO), the following have been observed:
"Although the success rate of students in the applied math course has been steadily
on the rise, increasing from 40% five years ago to 47% in 2014, it has remained
persistently low, and more than half the students enrolled in this course are
still not meeting the provincial standard.", and
"Of the students in the Grade 9 applied math course who did not meet the standard,
90% had also not met the standard in Grade 6."
Results for the Toronto District School Board (from 2009 to 2014)
Academic Stream
Year: Number of Students: Meeting Provincial Standards:
2009-2010 13239 81%
2010-2011 13034 81%
2011-2012 12621 83%
2012-2013 12329 83%
2013-2014 11892 82%
Applied Stream
Year: Number of Students: Meeting Provincial Standards:
2009-2010 6175 26%
2010-2011 5756 30%
2011-2012 5253 34%
2012-2013 4972 32%
2013-2014 4626 34%
Provincial standards are measured as follows from the following achievement chart.
(*2) Motivation (Intrinsic vs Extrinsic):
"Some students have a genuine interest in the subject (an intrinsic motivation);
while others may see their degree as little more than a means towards a lucrative
career (extrinsic motivation); others may simply be trying to please their
parents or family (social motivation)".
I believe that this point should not be lost on any analysis of why students
succeed (or perhaps do not succeed) given that it plays such a vital role
in understanding why students "give up" (i.e. drop the course) when they
experience setbacks as they proceed through the course and program.
This also led me to propose a very simple (yet perhaps effective) strategy
for determining from the very outset which students should be considered
"at risk" vs those who should not.
A simple questionniare asking students the following:
"Why they chose this program?" or
"What they hoped to achieve after they graduate?"
should flag students as "at risk" if any of the responses are deemed as
extrinsic motivations!
(*3) Multiple Skills/Processes:
"Teachers will be familiar with students who can follow the lectures in the
programming course, who can dissect and understand programs, but who are
totally incapable of writing their own program (i.e. They have not mastered
all the processes; they can code, but they cannot produce an algorithm)".
Most (if not all) programming instructors of any experience will have come across
students for whom tracing through the execution of code to determine the output
(a walkthrough) of a program is relatively simple and many excel at such an exercise.
Yet, when that same student is asked to solve a word problem requiring the development
of their own algorithm and logic skills, is incapable of creating the required code.
Surprisingly, the reverse is also observable in many instances (i.e. some students
can develop the required algorithms and write solutions to word problems, yet have
great difficulty concentrating and navigating through the execution of existing
blocks of code)!
For many instructors, this second point sounds counterintuitive (i.e. How is it
possible for a student to be able to write programming code, yet not be able to
trace through and decipher existing logic?).
Over the years, I have seen a great many examples of students in both categories.
The difficulty in case #2 (students who can solve problems but who cannot trace
through existing code) is that for many students, the level of concentration
and patience required to carefully step through logic with which they are not
familliar (i.e. they did not create) is yet another skill that must be mastered.
Further, because of the novelty of many language constructs and because learning
to program is a "building block" activity, a small error in a computation or
lack of familiarity with a specific construct can make all the differnce between
output that is correct vs output that is gibberish.
It has therefore become clear to me over the years that a mastery of a very different
set of skills is required in order to become an accomplished programmer.
(*4) Educational Novelty:
"In his classic article on teaching programming (which should be required
reading for all who teach programming) Dijkstra argues that learning is a
slow and gradual process of transforming the "novel into the familiar".
He goes on to suggest that programming is what he terms a "radical novelty"
in which this comfortable tried and tested learning system no longer works.
The crux of the problem is, according to Dijkstra, that radical novelties
are so "disturbing" that "they tend to be suppressed or ignored to the extent
that even the possibility of their existence ... is more often denied than
admitted".
After reading this paragraph, carefully reading through Dijkstra's paper,
and reflecting on all of the e-mails, questions, and grading of test papers
I have reviewed over the years, a remarkable pattern began to emerge.
The elements of the curriculum that were consistently problematic and gave
students the most difficulties were those that presented them with the greatest
amount of "novelty"!
From my own experience in teaching introductory C programming, the areas that
required students to shift their understanding included:
1. Data being accepted from standard (buffered) input vs from function parameters.
2. Understanding the distinction between parameter passing by address vs by copy.
3. Understanding the difference between the values stored by pointers vs
regular variables.
4. Understanding the shift in how data is accessed by way of files on disk vs
data from standard input, vs from function parameters, vs variables in
volatile memory, etc.
If you think carefully about the courses you deliver and reflect upon the areas
that routinely cause students difficulty, it may be possible to attribute
such difficulties to this same idea of "novelty".
(*5) Interest:
"Learning programming can be very dull.
Lectures covering the details of syntax are never going to be especially
inspiring, and exercises that involve simple mathematical manipulations of
collections of student marks, stock levels, baseball statistics, or bank account
details are never going to set the pulse racing. Yet a glance in many
programming texts will yield many turgid examples of each of these.
At its best, programming can be an enjoyable, creative activity, and many
students derive great enjoyment from their programming. They enjoy it
even more (and learn more) when they are allowed to work on assignments
that inspire them".
This point also led me to examine what role interest and motivation plays in
learning and memory and so I proceeded to review much of what I was already
familiar with regarding the biological basis of memory and learning.
While a detailed examination (at the cellular level) of the mechanics of synaptic
and/or structural neuroplasticity is necessary in order to understand how long term memory
is facillitated, it is sufficient to say that biochemical factors involved
in "mood and interest" (and thus motivation), play a critical role in the
underlying processes involved.
From Principles of Neural Science 5th Edition
Chapter 66: Cellular Mechanisms of Implicit Memory Storage and the Biological
Basis of Individuality.
"In all forms of learning, practice makes perfect. Repeated experience converts
short-term memory into a long-term form and involves the connections at several
synapses, including those between sensory and motor neurons. However, it also
involves the growth of new synaptic connections. Five spaced training sessions
(or repeated applications of serotonin) over approximately 1 hour produce long-term
sensitization and long-term synaptic facilitation lasting 1 or more days;
continued spaced training over several days produces sensitization that persists
for 1 or more weeks. Long-term sensitization, like the short-term form,
requires protein phosphorylation that is dependent on increased levels of cAMP.
The conversion of short-term memory into long-term memory, called consolidation,
requires synthesis of messenger RNAs and proteins in the neurons in the circuit.
Thus, specific gene expression is required for long-term memory.
The transition from short-term to long-term memory depends on the prolonged rise in
cAMP that follows repeated applications of serotonin (an excitatory neurotransmitter)".
It's not a remarkable revelation that people tend to learn best what they
enjoy doing, and along with motivation, this fact also plays a key role in the
formation of long term memory. Yet, this fact is lost on many educators who write
books or study guides that are too technical, use examples that are overly complex
(or perhaps too trivial), or that do little to engage student interest.
It is true that different students may have very different learning styles and also that
what interests one student may not interest another, yet it should be entirely possible
(with a little imagination and creativity) to design questions, assignments, and content
with broad appeal.
This past semester for example, students in IPC144 were required to complete a final
assignment where they would have to write a portion (broken down into several
modules) of the code necessary to create printable examples of the popular game Sudoku.
The final output was required to appear as:
PLAY IPC144 SUDOKU
+-----+-----+-----+
| 2|4 5|8 1|
|5 1| 9 | 4|
| 6 |1 |2 |
+-----+-----+-----+
| 1 | 7 | 2 3|
|6 7| 2 | 8|
|8 |5 9| 6|
+-----+-----+-----+
| 5 |7 2|6 3 |
|2 4 | | 9|
| 6|9 8 |4 |
+-----+-----+-----+
In fact, one of my student's rationalized that because he had a sibling that
routinely spent $3 every 2 weeks on Sudoku puzzle books from the local bookstore,
that if he completed his assignment and used his program and printer to print
the equivalent of a dozen or so books, that the money he saved the family could be
more "intelligently" used to buy a popular game for his own gaming console!
Now that's creativity!
So, where are we now?
It seems clear that if programming faculty are ever to develop effective teaching
strategies that will serve to significantly improve the success rate of introductory
(and perhaps all) students, that careful consideration of all of the factors sited
above will have to be made in the design and implemenation of such strategies.
We have to at least acknowledge the following:
1. That learning to program represents a radical novelty requiring a hierarchy of skills
that students have either never or seldom seen prior to their enrollment in a
computer studies program.
2. In Ontario, (at current) it is not unrealistic to extrapolate (given recent EQAO results)
that students entering the college system have poor mathematics, and hence, poor
problem solving skills that are adversely affecting their ability to design and implement
algorithms to solve reasonably complex (and often basic) problems.
3. Students graduating high school have become increasingly reliant upon (and interact almost
exclusively with) devices (laptops, smart phones, tablets, etc) and reverting to
being evaluated with paper and pencil represents (in and of itself) a "radical novelty"
with which fewer and fewer students are able to cope.
4. Given their youth, level of maturity, and waning ability to focus on any single topic
for long periods of time, it is increasingly important and encumbant upon educators
to deliver material that is interesting and motivates students to stay engaged in
what they are learning. It is also critically important that the types and number of
evaluations not be burdensome and that information be directed at students in a strategic
way so as not to be overwhelming.
5. And finally, as a dear colleague of mine at the School of Biological Sciences and
Applied Chemistry at Seneca@York (and a person for whom I have the utmost respect and
admiration) was kind enough to remind me: "A little encouragement goes a long way"!
It is not unreasonable to assume that high school students may not have had much
of an opportunity to interact with teachers in the classroom, and in fact, I have observed
that most say very little -even when prompted!
So, showing empathy, making students feel that you are approachable and "on their side",
spending a little extra time to answer questions, helping them during office hours, etc.,
can make all the difference in the world to a student who may be afraid to ask for help
on their own.
I know that many of you are already aware that there is no more fulfilling and
rewarding experience than to know that you have contributed positively to the
a student's educational development!
Current framework for course delivery (IPC144) at Seneca College:
Prerequisites: Grade 12 Mathematics: (C) or (U) or Grade 11 Mathematics: (U) or (M).
Grade 12 English: ENG4(C) or ENG4(U).
Entrance Test/Eligibility: None.
Delivery: Hours of instruction per week: 4 (2 lecture / 2 laboratory).
Seneca's Academic Plan: 80% success rate in first semester.
Language of Instruction: C
My Recommendations:
1. Investigate changing (or adding to) the CPA/CPD/CPAC high scool prerequisite(s) to:
Grade 12 Mathematics: (C) or (U) or Grade 11 Mathematics: (U) or (M), and
Grade 12 English: ENG4(C) or ENG4(U), and
Grade 11 or 12 Computer Engineering Technology TEJ3M or TEJ4M.
2. Streamline the current IPC144 curriculum in order to reduce the amount of "novel"
language constructs covered, thereby creating a more gentle learning curve.
| |
N | * N |
O | * O | *
V | * V |
E | * E | *
L | * L | *
T | * T | *
Y | * Y | *
| * | *
| * | *
|* | * * *
+------------------------------ +------------------------------
Current learning curve Proposed learning curve
TIME TIME
Proposed (reduced) vocabulary (keywords) and operators to be used in teaching IPC144:
keywords: operators:
char arithmetic (+, -, /, *, %, =, ( ) )
do relational (>, >=, <, <=, ==, !=)
double logical (&&, ||, !)
else
float
for
if
int
long
return
void
while
constructs:
computation, decision control, iteration, functions, arrays (1D only)
libraries:
<stdio.h>
excluded: all other operators (*, ++, --, +=, -=, *=, /=, ? :), pointers,
all other library functions (except those in <stdio.h>) 2D arrays, files.
Delay the coverage of excluded items to semester 3 (OOP345).
To this end, I have taken the liberty of rewriting the IPC144 fall 2014 final exam
such that it would adhere to these reduced vocabulary, library function, and operator
requirements (copies of both are available here).
IPC144 143 Final Exam (unmodified)
IPC144 143 Final Exam (simplified vocabulary)
What I discovered in rewriting the final exam was that while it was syntactically
simpler, the programming questions were consequentially more challenging given that
their reliance on library functions was removed!
I can't help but think that it is far more desirable to develop students that can
write their own (better) algorithms than have them simply rely on pre-written
ones found throughout various <library.h> header files.
3. Allow for adequate repetition of covered material and introduce examples with
at least 4 levels of increasing complexity in order to promote a "deep"
understanding of language constructs and associated algorithms.
Example to illustrate nested loops and their implications:
********** for(i = 0; i < 5; i = i + 1) {
********** for(j = 0; j < 10; j = j + 1) {
********** prinf("*");
********** }
********** printf("\n");
}
Reasonable 1st semester test question and solution:
* for(i = 0; i < 10; i = i + 1) {
** for(j = 0; j < i + 1; j = j + 1) {
*** prinf("*");
**** }
***** printf("\n");
****** }
*******
********
*********
**********
Test question and solution that current 1st semester students struggle with:
* for(i = 0; i < 10; i = i + 1) {
*** for(j = 0; j < 10 - i - 1; j = j + 1) { /* spaces */
***** prinf(" ");
******* }
********* for(k = 0; k < i * 2 + 1; k = k + 1) { /* stars */
*********** printf("*");
************* }
*************** printf("\n");
***************** }
*******************
Unreasonable test question question for current 1st semester students:
0 for(i = 0; i < 10; i = i + 1) {
010 for(j = 0; j < 10 - i - 1; j = j + 1) { /* spaces */
01210 prinf(" ");
0123210 }
012343210 for(k = 0; k <= i; k = k + 1) { /* 1st half of sequence w/ mid digit */
01234543210 printf("%d", k);
0123456543210 }
012345676543210 for(l = i - 1; l >= 0; l = l - 1) { /* 2nd half of sequence */
01234567876543210 printf("%d", l);
0123456789876543210 }
printf("\n");
}
4. Solicit recent graduates, senior level students, and younger faculty for
recommendations on the kinds of materials and examples that would most interest
new students in an effort to increase their motivation for completing required
course evaluations (labs/assignments).
5. Instructors teaching in multi-section introductory courses should have a
minimum of 5 iterations teaching programming courses to college level students.
Where this is not possible, new faculty should partner with experienced faculty so
that recommendations on types and level of difficulty of evaluations,
marking standards, and teaching approaches be discussed to ensure consistent
delivery of course material across all sections.
To this end, it is recommended that faculty post the material they use in class
(examples, tests, quizzes, labs/workshops) on their website to promote
collaboration (sharing of examples and ideas) as well as to provide additional
varied reference material.
Faculty should collaborate to create a pool of assignments and labs that can
be recycled every 6 semesters.
6. Evaluations should be designed so as not to be "all or nothing" (i.e. a walkthrough
that would be unsolvable if a student makes a single error). Walkthroughs in IPC144
(or any introductory course) should be designed such that output appears at multiple
stages of the program and that blocks of code are not reliant on other blocks.
Problem solving questions should be written in such a way as to require "reasonably"
complex algorithms that are commensurate with examples and theory presented in class
(see examples above).
7. Faculty should perform informal surveys of students to ascertain the following:
a) Why did they choose this program?
b) What are their long term career goals?
c) Do they have any previous programming experience, and if so, what?
What course did they take? What knowledge did they acquire?
This is to be used in an effort to immediately identify "at risk" students
(i.e. students who have enrolled in a diploma/degree program for extrinsic reasons
or who have little or no computer related skills).
Thanks for reading!
Danny Abesdris
References:
On the Difficulty of Learning to Program - Jenkins (2001)
URL: http://www.psy.gla.ac.uk/~steve/localed/jenkins.html
Teaching Programming A Journey From Teacher to Motivator - Jenkins (2001)
URL: http://www.ics.heacademy.ac.uk/Events/conf2001/papers/Jenkins.htm
On the Cruelty of Really Teaching Computer Science - Dijkstra (1988)
URL: https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
Difficulties In Learning Programming: Views of Students
URL: http://www.academia.edu/4230359/DIFFICULTIES_IN_LEARNING_PROGRAMMING_VIEWS_OF_STUDENTS
Long term potentiation and synaptic plasticity - Khan Academy
URL: http://www.khanacademy.org/test-prep/mcat/processing-the-environment/memory/v/long-term-potentiation-and-synaptic-plasticity
Neuroplasticity - Khan Academy
URL: http://www.khanacademy.org/test-prep/mcat/organ-systems/neural-synapses/v/neuroplasticity
Modulation of long-term potentiation by the glycine site of N-methyl-D-aspartate receptor in rat hippocampal CA1 pyramidal cells
URL: https://curve.carleton.ca/system/files/theses/27201.pd
Neuroscience - Long-Term Potentiation - Carleton University
URL: https://www.youtube.com/watch?v=vso9jgfpI_c
Principles of Neural Science - 5th Edition
(Kandel, Scwartz, Jessel, Siegelbaum, Hudspeth) c 2013
Chapter 65: Learning and Memory
Chapter 66: Cellular Mechanisms of Implicit Memory Storage and the Biological Basis of Individuality.
Chapter 67: Prefrontal Cortex, Hippocampus, and the Biology of Explicit Memory Storage.
EQAO Provincial assessments report 2014 (PDF)
URL: http://www.eqao.com/pdf_e/14/infographic-2014-provincial-assessments.pdf
EQAO Provincial board results (pg. 2 province wide results by year) (PDF)
URL: http://www.eqao.com/ProvincialReport/Files/14/PDF/provincial-report-secondary-school-board-results-2014.pdf
Ontario Math Grade 11/12 Curriculum (PDF)
URL: http://www.edu.gov.on.ca/eng/curriculum/secondary/math1112currb.pdf
Ontario Curriculum Grade 11/12 Technological Education Curriculum
URL: http://www.edu.gov.on.ca/eng/curriculum/secondary/teched1112curr.pdf
Stephanie Ditta
Professor
School of Biological Sciences and Applied Chemistry Seneca@York
B.Sc., M.B.A. (Queen's), M.Sc. (Western), Ph.D. (Toronto)