On Teaching Programming

Being involved with teaching young students to code, I have come to the tentative conclusion that many coding kids have not actually been taught programming. This has been going on for a while, so some of this cohort are now themselves teaching others.

I have noticed that many people doing programming actually lack many of the fundamental skills that would make their programs efficient, less buggy and even just functional.

A few years back, Esther Schindler wrote an article Old-school programming techniques you probably don’t miss (ComputerWorld, April 2009).

Naturally, many (most!) of the things described there are familiar to me, and it’s interesting to review them. But contrary to Esther, I still do apply some of those techniques – I don’t want to miss them, as they serve a very important purpose, in understanding as well as for producing better code. And I teach them to students.

Programming is about smartly applied laziness. Students are typically aghast when I use that word, which is exactly why I use it, but the point is that smartly applied laziness is not the same as slackness. It’s simply a juicy way of describing “efficient”.

---

Suppose you need to shift some buckets of water.  You could carry one bucket at a time, but you’ll quickly find that it’s hard on your arm and shoulders, as well as wasting the other arm you have. So we learn that if you have more than one bucket to shift, carrying only one bucket at a time is not the best way of going about it. Similarly, trying to carry three or more buckets is probably going to cost more time than it saves, as well as likely spilling water all over the place.

Thus, and this was of course worked out many centuries ago, carrying two buckets works best and is the most efficient as well as being quite comfortable – particularly when using a neat yet simple tool called a yoke (as pictured).

Inevitably, most kids will have at some time explored this issue themselves (perhaps while camping), and generally come to the same conclusion and insight. This is possible because the issue is fairly straightforward, and not obscured by other factors. In programming, things are not always so transparent.

---

Our modern programming tools (high-level languages, loose typing, visual programming, extensive APIs and libraries) enable us to have more convenience. But that convenience can only be applied judiciously when the programmer has the knowledge and skills required to make appropriate judgements. Without that, code can still be produced rapidly, but the results are not so good.

Some would say “good enough”, and that is somewhat true – when you have an abundance of computing power, memory and storage, what do a few bytes or cycles matter? But add together many of those inefficiencies, and it does become a rather dreadful mess. These days the luxury of abundance has become seriously abused. In our everyday life using laptops, smart-phones, tablets and other devices, we frequently encounter the consequences, and somehow regard it as “normal”. However, crashing apps (extreme case but very common) are not normal, and we should not regard any of this as good enough.

I see kids being taught to code using tools such as MIT’s Scratch. I reckon that’s fine as a tool, but in my observations so far the kids are only being shown how to do specific things the particular app or environment. Some kids will have a natural knack for it and figure out how to do things properly, others will plod along and indeed get through by sheer determination, and some will give up – they might conclude that programming is not for them. I think that’s more than a pity. It’s wrong.

When you think about it, what’s actually happening… in natural language, do we just give a person a dictionary and some reference to grammar, and expect them to effectively use that language? We wouldn’t (well actually, it is what my French teachers did, which is why I didn’t pick up that language in school). And why would computer programming languages be different?

Given even a few fundamental programming techniques, the students become vastly more competent and effective and produce better code that actually works reliably. Is such understanding an optional extra that we don’t really care about, or should it be regarded as essential to the teaching?

I think we should set the bar higher. I believe that anyone learning programming should learn fundamentals of how and why a computer works the way it does, and the various techniques that make a computer program efficient and maintainable (among other attributes). Because programming is so much more than syntax.