![\"Decorative](\"http:\/\/blogs.kcl.ac.uk\/proged\/files\/2024\/12\/guides-6-1024x502.png\")
<\/p>\n<\/p>\n
One common pattern of programming teaching \u2013 especially in books and other written material, but also in in-person teaching \u2013 is the focus on the product, rather than the process.<\/p>\n
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.<\/p>\n
The problem with this is that the solution appears \u2013 apparently in one step out of the ether \u2013 in its entirety.<\/p>\n
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.<\/p>\n
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 \u201cI am just not a good programmer\u201d.<\/p>\n
The fact that we all<\/em> work like this \u2013 write some code, discover mistakes, correct, change our minds, slowly build \u2013 must be one of the best kept secrets in programming.<\/p>\n For you as a teacher this means: Don\u2019t just teach your pupils what the correct program looks like, teach them how to get there<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":" One common pattern of programming teaching \u2013 especially in books and other written material, but also in in-person teaching \u2013 is the focus on the product, rather than the process. The usual structure is: (1) Here is a problem. (2) … Continue reading