One of the things I notice that pupils don't often do is play with code. They don't ask themselves, "what if I change this?" This was definitely part of how I taught myself to code and I still use it when I meet something new (and poorly documented!) Just because they don't do it by choice, that doesn't mean we can't ask them to do it.
Having introduced loops, I would ask pupils to do the exercise below. You might be surprised that quite a few will struggle. The third exercise, for example, will probably confuse quite a few of them. I would go through this one on the board asking:
Try the loop example yourself
Now change it so that it outputs
1. numbers from 5 to 20 (inclusive)
2. numbers from 10 to 50 in twos
3. numbers from 30 down to 10
These sorts of simple tasks allow you to check that pupils have really understood the example given
The third exercise above is likely to confuse quite a few. Try this approach to help them work it out:
It can be useful to give pupils partially completed code to finish off. I wouldn't give them code that they couldn't write themselves; I would question why you would do that. I would give them code that they could write but they don't need to at this point.
I recently came across Parson's Puzzles and I think they are a really good way of supporting early programming. You need to be very careful not to over-complicate them or they become quite incomprehensible but, used judiciously, I think they can help you identify misunderstandings without too much syntax getting in the way. Here are some of examples I am going to try out this term:
Testing: the use of brackets for print() and quotes for strings
Testing: mathematical operators (// and /) and the meaning of quotes
I make no apologies for my awful pun.
You can create your own standalone Parson's puzzles using websites like: http://parsons.problemsolving.io/ though, unfortunately, that does seem to limit you to one distractor.
The code you would need for something similar to puzzle 2 is:
print(35 // 10)
print(10 + 5)
print(35 / 10) #distractor
I would recommend that you build up a library of common errors that your pupils make and turn them into exercises. The things that come to mind are:
missing or unbalanced quotes
missing or unbalanced brackets
putting variables in quotes
lowercase true or false, instead of True or False
incorrect indentation
not incrementing a loop counter
using = instead of == for comparison
using round brackets instead of square brackets for indexing
running off the end of a string or list whilst iterating - Python's negative indexes can have some interesting side-effects here!
I have to work hard to avoid writing too many Maths-focused programming exercises. I love Maths and it's a natural fit but not everyone agrees! One useful tool to use is the good old turtle. You can use the turtle when you start to introduce loops and then develop those ideas for drawing different shapes or patterns.
Ihantola, P. & Karavirta, V., 2011. Two-Dimensional Parson’s Puzzles:The Concept, Tools, and First Observations. Journal of Information Technology Education: Innovations in Practice, Volume 10, pp. 119-132 available from http://www.jite.informingscience.org/documents/Vol10/JITEv10IIPp119-132Ihantola944.pdf
Harms, K J; Chen, K; and Kelleher, CL. 2016. Distractors in Parsons Problems Decrease Learning Efficiency for Young Novice Programmers. In Proceedings of the 2016 ACM Conference on International Computing Education Research (ICER ’16), 241–250. https://doi.org/10.1145/2960310.2960314
Parsons, Dale & Haden, Patricia. (2006). Parson's programming puzzles: A fun and effective learning tool for first programming courses. 52. 157-163 available from https://dl.acm.org/doi/pdf/10.5555/1151869.1151890?download=true