Seneca College

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.


On the Difficulty of Learning to Program (2001)
Tony Jenkins
School of Computing
University of Leeds, Leeds U.K.

+ 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

+ 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

    + 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

6. Departments should acknowledge that programming is difficult and supply
   adequate support to students.


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:

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%

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%

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

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:

|    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    (&&, ||, !)

   computation, decision control, iteration, functions, arrays (1D only)


   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            }

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


On the Difficulty of Learning to Program - Jenkins (2001)

Teaching Programming  A Journey From Teacher to Motivator - Jenkins (2001)

On the Cruelty of Really Teaching Computer Science - Dijkstra (1988)

Difficulties In Learning Programming: Views of Students

Long term potentiation and synaptic plasticity - Khan Academy

Neuroplasticity - Khan Academy

Modulation of long-term potentiation by the glycine site of N-methyl-D-aspartate receptor in rat hippocampal CA1 pyramidal cells

Neuroscience - Long-Term Potentiation - Carleton University

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)

EQAO Provincial board results (pg. 2 province wide results by year) (PDF)

Ontario Math Grade 11/12 Curriculum (PDF)

Ontario Curriculum Grade 11/12 Technological Education Curriculum

Stephanie Ditta
School of Biological Sciences and Applied Chemistry Seneca@York
B.Sc., M.B.A. (Queen's), M.Sc. (Western), Ph.D. (Toronto)

Any Browser!