Pondering Sheila’s thoughts on Why I Don’t Code?
, and mulling over some materials we’re prepping as revisions to the database course…
I see the update as an opportunity to try to develop the ed tech a bit, make it a bit more interactive, make it a bit “responsive” to students so they can try stuff out and get meaningful responses back
that helps them check what they’ve been doing has worked. (I’ve called such approaches “self-marking” before, eg in the context of robotics, where it’s obvious if your robot has met the behavioural goal specified in some activity (eg go forwards and backwards the same distance five times, or traverse a square).
Some the best activities in this regard, to my mind at least, can be defined as challenges
, with a “low floor, high ceiling” as I always remember Mike Reddy saying. Eg how perfect a square, or how quickly can your robot traverse it. And can it reverse it?
Most kids/students can get the robot to do something, but how well can they can it to do something in particular, and how efficiently? There are other metrics too – how elegant does the code look, or how spaghetti like?!
So prepping materials, I keep getting sidetracked by things we can do to try to support the teaching. One bit I’m doing is getting students to link database tables together, so it seems sensible to try to find, or come up with, a tool that lets students make changes to the database and then look at the result
in some meaningful way to check their actions have led to the desired outcome.
There are bits and bobs of things I can reuse, but they require:
1) gluing stuff together to make the student use / workflow appropriate. That takes a bit of code (eg to [make some IPython magic]);( https://github.com/innovationOUtside/ipython_magic_eralchemy
2) tweaking things
that don’t work quite how want them, either in terms of presentation / styling, or functionality – which means being able to read, as well as write, bits of code;
3) keeping track of work – and thinking – in progress
, logging issues, sketching out possible fixes, trying to explore the design space, and use space, including looking for alternative – possibly better – ways of achieving the same thing; which means trying to get other people’s code to work, which in turn means coming up with and trying out small examples, often based on reading documentation, looking for examples on Stack Overflow, or picking through tests to find out how to call what function with what sorts of parameter values.
Code stuff; very practical programmingy code-y stuff. That’s partly how I see code being used – on a daily basis – by educators working in a institution like the OU that claims to pride itself on digital innovation.
It’s also stuff that tests my own knowledge of how things are supposed to work in principle – as well as practice. This plays out through trying to make sure that the tech remains relevant to the educational goal, and ideally helps reinforce it, as well as providing a means for helping the students act even more effectively as independent learners working at a distance…
And to my mind, it’s also part of our remit, if
we’re supposed to be trying to make the most use of the whole digital thing… And if we can’t do this in a computing
department, then where can – or should – we do it?