I can still vividly remember my first lecture as an undergraduate computing student.  Monday morning.  9 o’clock.  Programming 1A.  C++.  Within the first five minutes we’re being talked to about data types.  I can remember some dazed expressions and confused discussions at the end of the lecture.  Not to mention the confused discussions 12 months later when, as a second year computer networking student, some of my classmates were still dragging Programming 1A and 1B resits behind them like a ball and chain.

Fast forward a little over a decade to January 2014 and I’m teaching second year networking students.  Second year students dragging a familiar ball and chain.  It might be a Java shaped inconvenience now, rather than C++, but it’s still first year programming baggage that the students could do without carrying.  Bring things to the present day and I find myself team teaching foundation students the Fundamentals of Programming.  The niggling mantra running through my mind?  “Please don’t let this be their ball and chain.  Please don’t let this be their ball and chain.  Please don’t let…”

But what’s the best way to prevent this from becoming the miserable outcome?  I’m not sure.  I’m more certain that there isn’t a magical solution to this.  For me the issue extends far beyond the choice of programming language or the object oriented versus procedural debate.  In the past week I’ve seen the panic that can set in when students are faced with a programming challenge.  Enthusiastic, intelligent students staring at a blank screen, gripped by fear and not knowing where to start.

This lack of knowing where to start seems important.  With some of the students there seems to be an assumption that, because it’s a programming module, the answer lies in the development environment.  But this is an environment that forces students to contort their thinking into strange syntax.  Syntax which must pass muster with the most pedantic entity they’ll ever have to deal with.  Creativity thwarted by semi-colons and the right shape of bracket.  Constraint by the bucket load.

We’re using the Arduino for Fundamentals of Programming.  At least this offers the chance to bring the abstract world of programming languages into a more meaningful, physical, real space.  Wires, LEDs, buttons, noisy things.  Making gadgets.  Tinkering.  Most of the students seem to like it.  But eventually the students need the code to drive the gadget and at this point we’re back to the blank screen problem.  We’re back to the syntax.

I acknowledge that, at some point, the students need to understand the language and be able to properly construct code.  If they can’t do that then eventually they’re going to have problems.  Just like my issues with French grammar and tenses back in the day.  But if the abstract concepts of programming are presented through equally abstract examples then it seems doomed to end in misery for a sizable chunk of the students.  As a student, demonstrating my competency with C++ by creating a program to check whether a series of cylindrical and cuboid boxes would or would not fit inside each other wasn’t a problem, but I can see why it was unfathomable for many others.

So, as far as my input into Fundamentals of Programming goes, I’m trying to keep it as real as possible.  Which is hard, because we’re still asking the students to make things that many probably wouldn’t otherwise make, using a programming language that many probably wouldn’t otherwise touch with a barge pole.  I’m hoping that having time away from the computers proves to be a good strategy.  We’re blessed with a classroom which provides a space for this kind of breakout activity.  So this is the first week when I’m going to present students with a group activity where they unpick a real world device, think about how it works and map out the steps of a program to control it.  The examples aren’t particularly thrilling (think traffic lights and lifts) but they are immediately identifiable and familiar.  Hopefully, because the problem is clear, the students can focus on the activities needed to solve it.  With a nod to Problem Based Learning, they’ll need to ask questions and they won’t have all the information they need.

My goal is to bring the tasks of identifying requirements and planning program functionality and structure into the students’ comfort zone.  Then, hopefully, with a clear plan to work to and an end product they can visualise, the prospect of satisfying the pedantic syntax monster won’t seem quite as daunting.