The essence of good programming is being able to approach a problem you've never seen before and plot your way through it using the various tools at your disposal. This is true of every programmer, from beginners right up to technical architects on huge projects. In fact, it's not just confined to programming. All engineering (and programming is certainly at least sort of engineering), involves this ability to approach a problem and find a solution in as novel or humdrum a manner as the situation dictates.
One of the first things we talk to our new students about is the idea of this "toolbox". We start with some simple commands: this is how you set the size of the window; this is how you draw a circle; this is how you draw a rectangle. We add to this as time goes on, but we never get to the point where we say "this is how you create a computer game". That, as you would expect, is instead a combination of all the little things into one big thing.
Starting out, their most powerful tool is not really any of these things but rather the instructors. The instructors know all the answers (or at least in the narrow confines of the assigned problems we do...), and we will always be available to give an extra nugget of information when a student is truly stuck.
After a number of weeks, however, something strange starts to happen. Bit by bit, they slowly stop needing us.
They still have questions, of course. Even advanced programmers occasionally need a sensible eye cast over a particularly intractable problem. More and more, however, their questions are answered before they finish asking them. As an instructor, all we need to do is nod along until they work it out for themselves. We're reduced to the roll of "nodding bear".
(A software team I worked on referred to it as the Stanford Bear, but I can find no sources which credit Stanford with the original innovation).
The idea of the nodding bear is that a programmer, as part of her/his debugging efforts, explains their problem to someone or something else. This can be an instructor, a colleague, or literally a rubber duck or stuffed bear. The typical question might begin with "so I'm trying to make this box disappear here and reappear here", before trailing off with "but when I check if the position is greater than the size - wait, shouldn't that be less than..? Never mind...". As the nodding bear, all the instructor has to do is nod along until the student arrives at the solution all of their own accord. Neat, right?
We're only six weeks in, so of course there are still lots of questions coming at us, and of course there is a wide range of abilities in each of our classes. All the same, it's great to slowly start becoming closer and closer to the proverbial Nodding Bear.
This week we revisited our basic drawing tools with most of the students, before moving on to making a box fly around the screen and respond to commands. More than ever before these students are starting to see how the tools they already understand can be combined in new and interesting ways.
Meanwhile the more advanced group were pressing ahead with their block dodging game. They progressed notably on their collision detection code, and generally made good progress towards the finished game. With a bit of luck we might need to find an entirely new project for them before the end of the year!