Computer programming is a fairly logical activity, right? We proceed step-wise (or at least piecemeal) using a finite set of tools to create a virtual machine that accomplishes…something. But how do we teach programming to a newcomer? Do we assume they have come in to the office with prior programming experience? Do we assume they think about the problem the same way we do? The answer to the last two questions should generally be no.
Do we assume they have come in to the office with prior programming experience?
We should always try to get a grasp on the most fundamental programming issue the learner needs help with as soon as possible. Many of us forget what it is like to be a learner—we teach a->b while assuming a. In my experience, total newcomers are understandably confused by why we currently wrangle with computer memory in languages like C to do simple tasks. One place to start is to remind them that solving problems with computer programming is often not purely logical—our solutions must conform to the rules of whatever language we are using, limitations of our machine’s memory, and many other factors. Often our solutions are approximations. Once they hear that there is no magical undertone to be attuned to in programming and it’s more a matter of study (and practice), the worry about programming usually diminishes a bit!
Do we assume they think about the problem the same way we do?
A student’s first coding exposure is probably not the best time to rant too harshly about overly-busy functions. If their program is one very busy function it’s often best to focus on helping them understand that function, with a passing mention that separating functionality out will be unavoidable as their programs get more complex. Building something that works and seeing their virtual machine complete its tasks is usually a much better alternative (and motivator!) than being stylistically perfect—at least at this stage.