Page 1 of 2
What tends to get overlooked when discussing STEM skills is that we need to teach algorithmic thought in the same way as needing to teach math, not just arithmetic.
Computer education seems to have been in the headlines for the last few weeks, for one reason or another. In most cases what can you say except "good", and perhaps "about time".
The idea, and one I subscribe to, is that we should all learn to program and this would make the world a better place. I'm not saying this just because I program. A widespread ability to apply algorithmic thought processes to any problem not just when working on a program is a good thing. Instead of just having a vague idea of how to approach a problem or project, the algorithmic mind puts together a fairly exact plan and also knows where the difficult bits are.
I have written before (What makes a programmer) about the simple fact that programmers often don't realize what their skill actually is. It is too easy to confuse what we do with the details of code, languages and data to be what programming is all about.
It is, but it is just the surface representation of what is going on deep inside. These inner workings are usually not discussed because they are not really of practical concern. Yet they are vitally important if we are to teach non-programmers how to program. (James, 1979).
One of the big problems we have with the programming education revival that is going on at the moment is that quite a few proclaimed experts on teaching programming are actually just expert programmers - and the two things are very different.
Doers aren't necessarily good teachers - in fact there is a fairly strong negative correlation between the two, even if it is only in popular opinion.
Imagine that you have spent a few months learning to juggle. You can do it, but you might not know how you do it. In this case, when it comes to teaching someone else to juggle, knowing how you do it isn't much help. But when it comes to programming it is vital.
When you learn to program something magical happens inside your head. You get a model of algorithmic processing, and this model has a life separate from the syntax, and even the exact semantics, of the language you just learned.
This is easy to prove because if you go on to learn a second and a third programming language you will learn them faster and you will identify commonalities that are surface expressions of the model inside your head. You have a way of thinking about problems that enables you to express solutions or even attempts at solutions in code. Asp soon as a problem is presented your brain starts to put together algorithmic fragments as if you were clipping bits of model railway track together to get from the problem to the solution.
This is also the reason why it is just fine to use graphical programming languages like Scratch to teach programming. You can absorb the skill of planning and building an algorithm using clip-together blocks just as easily as writing code.
However, there is one important skill that isn't readily acquired using graphical programming languages and this is the ability to transform the flow of control from how it might be in you head into a textual left-to-right top-to-bottom flow. For example, you can show a beginner a diagram for a conditional that has two alternative branches of instructions running parallel:
Then you can show them the classic if..then..else construct where, of course, the two alternatives are not set out on the page next to each other. The then comes first and below it the else follows. A very common error for a beginner, is to mistakenly think that the else part is executed following the then because this is the usual flow of control.
It takes time to learn to build an algorithm in your head, and it takes even more time to learn to express that algorithm as a textual coding. These are two separate skills.