Just over ten years ago, I stopped being a university lecturer in a computing science department and started working full-time in my own company. It wasn’t an easy decision to make, but particular life choices meant I had to forswear lecturing in favour of a “proper job”. Over those ten years of university I taught courses on most aspects of computing science, from software metrics to concurrency via formal program specification – but perhaps the hardest course to teach was introductory programming.
There are many reasons for this. Programming is very much part of the DNA of computing, and if you want to be a computer scientist then you’ll need a sound knowledge of what programming is all about, and probably a practical mastery of it too. That being so, there are heated arguments about the precise methods that should be used to teach programming, and what should and shouldn’t be taught. Half the problem is that there’s no consensus over the answers to many of the questions that arise, and in particular there’s no agreement about what kind of programming language should be taught.
Even where there is some agreement about the type of programming to teach, the choice of language remains fraught. Should you teach a language that’s “good for teaching”, or do you teach a language for which there are “immediate job opportunities”? Some decisions had already been made on the course I taught: I was to teach object-oriented programming and I was to do it in C++, but making sure that the students could also write plain C.
No language can prevent a bad programmer writing bad programs, but some languages do give the next person who has to read the bad code a sporting chance of understanding it
Neither of these decisions made my life easy: I had to teach two styles of programming instead of one, and using a language that’s huge, complex and, at the time, was poorly implemented. C++ isn’t exactly a bad language but, like C itself, it makes it too easy to write bad programs. Of course, no language can prevent a bad programmer writing bad programs, but some languages do give the next person who has to read the bad code a sporting chance of understanding it!
So why bring this up now? Because a couple of times last year I was asked how someone should go about learning to program nowadays, and I thought I’d take a look here at the resources out there to help someone who wants to learn programming. For the most part I’ll be looking at introductory programming, but I’ll also mention some resources for those who can program already but want to try a different language.
Learning to program
When I started at university I was in the first year who didn’t have to use punched cards for their programming course – we had access to interactive terminals! Some people even got access to personal computers such as the BBC Micro, which were probably better than the minicomputer we had to use, but that was rare. Whenever we completed a program it brought a real sense of achievement, because the computer we worked on seemed as primitive as the program we’d just written. Nowadays, any student program will of necessity be far more primitive than the system it was written on.
When I taught programming, for example, around week three I’d set an exercise to write a program that reads in two numbers and outputs a multiplication table – type in 12 and 10 and it would print the “twelve times table”. This merely involved writing a simple nested loop, but there were certain details the students had to get right. For example, the table had to be nicely formatted with all the numbers lined up properly, so the column of numbers – 0, 12, 24 and so on – needed to be right-justified by putting spaces in front of some of them. However, they hadn’t yet been taught how to format output, so they had to work this out for themselves.
Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.
