Three years ago, the landscape for ICT teachers in the UK
began to change. I realised that I would need to adapt to teach Computing,
specifically Computer Science as the policy documents seemed to suggest that
this was where the future of ICT was going. I’ve spent the last 2 years
teaching Computing with a strong bias towards teaching Programming. This is
what I’ve learnt so far.
Rote learning and testing
Some things are best learnt by rote. Programming is not one
of them. Multiplication tables and French irregular verb endings are something
which you will just have to remember. However, a function to calculate a
multiplication table in Python is not something that any professional
programmer would spend time memorising by rote. I remember when I first tested
students, I expected them to produce working programs without referencing their
prior programs or even using the Web. This is how controlled assessments and
exams work in (say) Science so why not Computer Science. The reality is that,
it’s not realistic or indeed necessary for 11 year old students to remember the
exact syntax for sequences, selections or iterations. It’s not necessary at
GCSE or A-Level (or even for professional programmers and software developers) to remember their past
solutions. I did not know about this until I went on exam board training!
My leveraged observation coach had once advised me to use
SPOT to make students more independent and I now consider it a vital tool for
teaching programming.
Self-Persevere, be resilient and keep
debugging because every failure is one step closer to success
Peer-Use your peers, ask the people sat
next to you.
Other-Use other resources. All good programmers use their old code, websites (including Youtube), documentation and forums. Because there are very few problems which other programmers haven’t tackled already.
Teacher-The teacher is your last resort! He or She will be understanding and helpful provided you have exhausted all the steps above.
Other-Use other resources. All good programmers use their old code, websites (including Youtube), documentation and forums. Because there are very few problems which other programmers haven’t tackled already.
Teacher-The teacher is your last resort! He or She will be understanding and helpful provided you have exhausted all the steps above.
Expecting students to produce the same correct answer
In many Sciences, there is only one correct answer. Computer
Science deceives us in that there is rarely only one correct answer! Linked to
the previous mistake I made, I spent a lot of time in my first year by
focussing on the correct solution.
Too much programming and too soon!
I was anxious to teach my students programming in their very
first term in Year 7 for fear that they would not be able to complete their
Controlled Assessment in three years’ time. Looking back, it is quite surprising that
despite my insistence on drilling the importance of Python syntax, indentations
and parentheses, my students still loved programming. I think it was because of
the way the subject was sold. They knew that very few 11 year olds across the
country were also writing programs using Python at the time.
Whilst learning a programming language is an important part
of Computing, something else needs to come first! My students were generally
enthusiastic and enjoyed programming, but the focus was all wrong. JeannetteWing and Mark Dorling frequently speak about Computational Thinking and it is only after two years that the
penny finally dropped for me.
In Mark Clarkson’s unofficial guide to Teaching Computing he
provides the following advice for new Computing teachers:
"For the first
half-term we do nothing but logic problems without going near a computer
(search CAS Online for good examples) and in the second half-term we look at
basic Python programming, covering input, output, variables, assignment, if
statements and loops (WHILE and then FOR)…"
Jonathan Torbitt’s curriculum also reflects this, with a
focus on problem solving first and programming syntax second:
Many other successful departments follow this approach of
teaching the problem solving through Computational Thinking before teaching any
programming.
In summary, do not rush to teach students the syntax to a
programming language. Teach them decomposition-how to break down problems into
smaller ones first decomposition. Then see if they can recognise any patterns-have
they solved something similar before? Is there any repetition within the
problem? Get them to strip away un-necessary detail and form a general
model-this is called abstraction. Lastly, before students start programming,
they need to plan their algorithms i.e. they need to solve the problem by
planning it step by step.
Planning for success instead of failure
We all write assessments and then test it out on ourselves
to see if we can do it, we’re planning for success and expect students who work
hard to score 100%. Yet when students fail, we wonder why and we wonder why
they all make similar mistakes. Mark Guzdial has applied an alternative
approach based on Philip
Sadler’s research at Harvard University. This approach involves the teacher
completing an assignment themselves and trying to figure out what are the most
likely wrong answers i.e. the most common ways in which students might fail or
misinterpret a question. Essentially, what you’re doing is finding out all the
common misconceptions and planning for these in your teaching. Philip Sadler’s
research suggests that this one skill is what differentiates the best teachers
from the rest:
“If teachers are to
help students change their incorrect beliefs, they first need to know what
those are…The results showed that students’ scores showed the most improvement
when teachers were able to predict their students’ wrong answers.”- Philip
Sadler
Only rewarding success
“The first thing to
realise is that programming is a difficult and different skill. Students are
not used to struggling, solving their own problems or repeatedly failing. They
have spent 10 years or more learning to give the correct answer, and if they
didn’t know it, then to learn it…
… In programming, students need to try, to
fail, to realise that the sky has not fallen on their heads and to try
something different. It is incredibly difficult to watch a student struggle and
not dive in with the answer, but the process, the techniques and the strategies
are far, far more important than simply getting a program that does what you
want.”-Mark Clarkson
Computing is a unique subject in that you will spend more
time failing than you do succeeding. Mark Guzdial’s advice is to create an
environment where it’s OK to make mistakes. Let students know that even their
teacher will make mistakes. David Batty
likewise emphasises how important it is to fail in front of your students and
not to over-plan your code so that it is bug free. Do the programming live and
debug it live. Nobody in the world can program without making mistakes. Mistakes
are teachable moments; Guzdial goes on to state that you should then talk through
your debugging slowly- This is what I thought, this is what I want the code to
do, this is what I will try next. Referencing Collin’s research on CognitiveApprenticeship, Guzdial states that thinking
aloud plays a pivotal role in helping students become better programmers.
Karen Hume takes this rewards approach further by stating
that we should reward less and celebrate
more. Rewards can create a ceiling; once a student has been rewarded for
success, they stop because they see success as a destination instead of a
journey. Rewards also signal that the learning has not intrinsic value. By
praising effort and celebrating student’s debugging, we’re more likely to
develop successful programmers with a growth mindset.
But what about success?! We’d be lying to ourselves if we
did not acknowledge that success is
important and Brad
Miller and David Ranum suggest the following for new programmers:
1) Start Small. This is probably the
single biggest piece of advice for programmers at every level. Of course it’s
tempting to sit down and crank out an entire program at once. But, when the
program – inevitably – does not work then you have a myriad of options for
things that might be wrong. Where to start? … How to figure out what went
wrong?... So, start with something really small. Maybe just two lines and then
make sure that runs ok. Hitting the run button is quick and easy, and gives you
immediate feedback about whether what you have just done is ok or not. Another
immediate benefit of having something small working is that you have something
to turn in. Turning in a small, incomplete program, is almost always better
than nothing.
2) Keep it working. Once you have a small
part of your program working the next step is to figure out something small to
add to it. If you keep adding small pieces of the program one at a time, it is
much easier to figure out what went wrong, as it is most likely that the
problem is going to be in the new code you have just added. Less new code means
it’s easier to figure out where the problem is.
This notion of Get something working and keep it working
is a mantra that you can repeat throughout your career as a programmer. It’s a
great way to avoid the frustrations mentioned above. Think of it this way.
Every time you have a little success, your brain releases a tiny bit of
chemical that makes you happy. So, you can keep yourself happy and make
programming more enjoyable by creating lots of small victories for yourself.
Pedagogy
Undergraduate Education !=
Secondary Education
We cannot expect eleven year olds to learn the same as we
learnt at degree level or whilst programming in the real world. Providing a
lecture and then expecting students to apply this material in the lab is a
highly ineffective way to teach programming at Secondary school. The pedagogy
for teaching programming is completely different. Guzdial’s research shows that
3 things certainly work: Paired programming, Peer Instruction and Media
Computation. Clarkson has found that the following works well in his classroom:
Regular programming
homework tasks and paired programming challenges during lessons ensure that
students keep practising, and in a safe and secure environment where it is OK
to fail. In fact failure must be celebrated as it means the student in question
has moved one step closer to a solution.
Balance and flexibility
Computing != Computer Science
Computing consists of three strands, Computer Science,
Digital Literacy and Information Technology. I knew this as I spent a whole
year meeting Teach First ICT teachers in a focus group setting and we
established that teaching only one of the three strands would be short-changing
our students. The current Computing Curriculum also reflects this with all
three strands equally weighted.
With exam pressure however, I have undoubtedly spent 70% of the year teaching Computing, specifically the OCR syllabus for GCSE Computer Science. My rationale was that if they start in Year 7 or 8, by Year 11 they’ll be flying. Luckily, I started early and have had ample time to learn from my mistakes! The biggest mistake has been teaching to the exam, the assessments change and even our department’s GCSE options have changed. Having visited three successful Computing departments, I have learnt that it is important to offer a balanced curriculum from Key Stage 3, all the way to Key Stage 5. In September 2016, we’ll be offering GCSE ICT alongside GCSE Computer Science and as a result, I will be re-planning Key Stage 3 to reflect this. I know that ICT won’t last much longer in its current state but this serves as a reminder to be flexible; plan for balance and plan for change.
Most of this post is about Pedagogy and is based on my own
experience and the articles/videos linked throughout the document and below. I
wrote a similar end-of-year reflection post last year which focussed on the
logistics and practicalities of setting up a Computing department, you can read
about that here.
Essential reading/viewing:
Mark Guzdial’s advice for Computing teachers:
