Tag Archives: teaching

Harry and the H-Quotient

Scene: we find ourselves in the nondescript office of Brunt Stickler, Head Teacher at Mokita High School. Stickler is tending to a virtual Zen garden on his tablet (the real desktop version made too much mess when he left a window open on a particularly windy day) by way of a distraction from the latest pile of management statistics on his otherwise empty desk. There is a knock on the door and in walks the slightly dishevelled Harry Juggler, Geography teacher at the school. Continue reading

Programming can be fun…

This is my attempt at a circuit and code to meet the requirements of the CTF3001 Fundamentals of Programming assignment.  I really enjoyed the challenge of making and coding this project and hopefully the students will too.  I particularly enjoyed the fairly open assignment brief which left room for creativity.  I also had more fun making a game than I did stacking boxes.

Programming and Comfort Zones

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.

Modelling the impact of planned interventions

Time for a brain splurge about one thread from a thought provoking meeting with MWJ earlier today.  I’ll sum Mark’s idea up as “what if you could reasonably accurately model the impact of a series of planned interventions on a simulated classroom?” and hope I didn’t miss the plot completely. Continue reading

Tolerance of the learning curve

Having read David’s post about Dwarf Fortress (I keep wanting to call it Gnome Fortress for some reason) I had a “quick” play.  Admittedly my interest in computer games peaked when I owned a SNES (a D-pad and six buttons really should be enough for anything) and since then my tolerance of computer game complexity just about stretches to Command and Conquer style offerings.

But there was something strangely compelling about Gnome Dwarf Fortress.  ASCII graphics: check. Near-vertical learning curve: check. Certain defeat: check.  It doesn’t sound like a winning combination, but I was compelled to delete it before addiction set in.

Afterwards I kept thinking about the link between a product’s learning curve and the willingness of the end user to invest time and energy in learning how to use the product sufficiently well to obtain what they consider to be a successful outcome.

Continue reading