![\"A](\"http:\/\/blogs.kcl.ac.uk\/proged\/files\/2024\/12\/guides-8-1024x502.png\")
<\/p>\n<\/p>\n
One common mistake (and yes, I think it\u2019s a mistake!) that I often see in teaching (and especially in textbooks) is to try to be exhaustive too early. When it is time to mention, for example, data types, you have to say all<\/em> there is to say about data types. Or if it is a textbook: since this is the chapter with data types, it has to have a table of all<\/em> the types and all their operations.<\/p>\n Since types are needed early, this lesson\/chapter comes early. Perhaps a pupil only needs to use a number and a string, but suddenly they hear everything about floats, booleans, chars, type conversions, widening casts, and whatever else there is to say about the intricacies of type systems.<\/p>\n The problem is that learners do not know which bits of the information is relevant right now, and which isn\u2019t. It\u2019s just stuff<\/em>.<\/p>\n The result: The relevant information is lost, the budding programmer is overwhelmed, learning is rote (and therefore boring), and no one but the author is happy.<\/p>\n The thing to do instead: Use a spiral approach. When encountering any concept for the first time, say only as much as is needed to get the task done. Get learners to get a result on screen without overloading them with detail. Then return to the topic again (and again) over the next weeks, each time deepening the discussion and understanding.<\/p>\n There are several benefits to it: First, you avoid adding cognitive load for no (immediate) gain. Let pupils concentrate on what is needed. Second, you get to the fun parts more easily and quickly. And thirdly, linear instruction doesn\u2019t work in programming anyway. Constructs in any modern language have circular dependencies, and you cannot fully explain everything in a single sequence.<\/p>\n By revisiting concepts multiple times, you can get to interesting results quickly, deepen understanding as learners develop, and discuss influences of specific language constructs on others, pointing out the (circular) dependencies of one language design element on the others.<\/p>\n","protected":false},"excerpt":{"rendered":" One common mistake (and yes, I think it\u2019s a mistake!) that I often see in teaching (and especially in textbooks) is to try to be exhaustive too early. When it is time to mention, for example, data types, you have … Continue reading