One common pattern of programming teaching – especially in books and other written material, but also in in-person teaching – is the focus on the product, rather than the process.

The usual structure is: (1) Here is a problem. (2) Here is a program (involving some new construct) to solve the problem. (3) Here is a discussion/explanation of the solution and the new construct.

The problem with this is that the solution appears – apparently in one step out of the ether – in its entirety.

In novice learners, this creates the impression that this is how experts work: If you know how to program, you will be able to think for a moment, and then just write down the solution.

They struggle with coming up with a working program, and even if they have an idea, they make mistakes, run into compiler errors, have bugs in their code, and think “I am just not a good programmer”.

The fact that we all work like this – write some code, discover mistakes, correct, change our minds, slowly build – must be one of the best kept secrets in programming.

For you as a teacher this means: Don’t just teach your pupils what the correct program looks like, teach them how to get there.