I've been discussing the topic of beginning coders with a couple other developers recently, and we seem to be at odds as to the best way to learn how to write code when you've never really done it before. I've been tutoring a couple co-workers with a few items, some purely elementary, and yet others are dangerously close to intermediate. However, my daughter is showing more and more interest in understanding exactly what it is that Dad does, and that's part of what creates the issue.
When the computer is a magical box that does things because the invisible gnomes tell it to do them, it's difficult to even begin to begin, if you catch what I'm saying. Elementary syntax, keywords, comments: these are all foreign words, and must be explained as if to a child (especially if you're really talking to a child).
But how do you take this person who is chomping at the bit with wild ideas for massive projects and teach them the most basic steps of the process, getting them to understand the complexity of what we do without inhibiting their desire?
A lot of my colleagues maintain that the "textbook" approach is best. As I've seen so often, "there's nothing that can't be built from a 'Hello world!' foundation." This seems to be the widely accepted view. Start with simple screen output, formatting, structure, and build from there.
I understand the premise here. It's the same as learning to talk. You start with simple words until you understand the reference to the objects and actions behind the ideas being conveyed, then you build up into phrases and eventually sentences.
But I disagree with the overall view. If I had spent my first few months "building upon a solid foundation of 'Hello world!' material," there's no way I would be a developer now. What a slow, boring, tedious process! Most of the people I know who are passionate about what they do started with a complete idea or a finished product, and began to disassemble the components to see how they all fit together. This applies to anything, not just software development.
My first programs were copied verbatim from the back of old "Compute!" magazines, which were, at that time, geared toward my beloved Commodore C-64. A half dozen hours of copying BASIC language code and a six pack of soda later, there was a crude sprite floating across the television screen that would seem to make anything it touched explode. When we got bored of playing the game (usually 15 minutes later), I could look at the code in more detail and see how to change the things I didn't like or try to understand some of the unfamiliar sections of the program.
Software development is all about the assembly of specific components and, of course, logic. If I show you seventy-five cents and an empty soda bottle, how in the world are you supposed to make anything out of that? You're missing the fact that I started with two dollars, purchased the soda from a vending machine, drank it, and had change left to spare. There's a lot of the story that gets left out if you only include the bare minimum components. You don't need to know how the vending machine works, or even understand the engineering behind the bottle cap. But you do need to know that they exist (and that you can study them later) in order to understand why you have the pieces remaining that you do.
Otherwise, you're still left with invisible gnomes doing magical things.
