Programming 102

Posts here have been conspicuous by their absence for a while, but things have been moving on. My energy has been focussed on delivering a revamped "programming 102", so development and business have been very much part time. I've just finished the marking and thought that would make a reasonable basis for a few observations.

The course teaches Java, building on a previous Java course. So the real basic basics have been covered. Whether everyone's got them or not is another thing. Any programming course has a tail of participants that, for various reasons, just don't quite click with the ideas. Like the difference between classes and instances, and how you go from one to the other. At the other end, some have pretty well developed skills already and need to be kept interested.

I mentioned a revamp, and apart from updating against Java versions and my own style of presenting the main change was to push test driven development. This isn't radical, but it was new for (I think) all of these students. The previous course had used BlueJ, with its very visual define / construct / inspect flow. Which I think it great for getting started. Testing makes more sense with a complex program that changes - which was the end goal. However, it provides a useful analogy to the visual approach with our more basic problems. At some point constructing objects and checking what they do by hand gets long winded. The few that hung onto BlueJ hit this about half way through. Testing allows that "I want one of these, one of those, to set that variable, and see what this method returns" flow to be scripted. Making the leap that its the same thing, done in a different way, needs a pushing - if you're finding coding hard then testing can feel like yet more code with this new set of commands to learn. If you've programmed before then for simple problems the value of getting out of the hacking rut can be a hard sell - and tests are written second for the marks. But, I think a significant proportion of my class found problems where "what do I want this to do?" or "this test lets me test a sequence of commands that can then be plugged in to the real code" was a useful step and even more found problems where making their code work was complex enough that the JUnit approach was more efficient than an ad-hoc testing approach.

So, for a first go, I think that worked. Plans for next time include videoed coding demos. Watch this space for a sample! All that teaching makes me want to stretch myself in a different way, and with a bit of luck learn something new. With a bit of luck something bloggable.