So, what's your story? Here's mine...
My first experience with a computer was back in the late 1980s when I was in fifth grade. My dad had decided it was time the family entered the computer age, so we trekked down to the local Sears and picked ourselves out a Packard Bell Legend IV. At the time it was quite cutting edge – the CPU could handle 12 million operations per second, it boasted whole megabyte of RAM, and 40 MB of hard drive space. Included with the MS-DOS operating system was an antiquated programming language – GW-BASIC. Since my dad had done a spat of programming back in his college days, he showed me how, with a little reading, a bit of typing, and a whole lot of patience and fortitude, one could spend the better half of a Saturday afternoon and have a program where colored squares raced one another across the screen to show for it. After seeing this, I was hooked.
Through junior high I continued to spend too much time in front of the computer working on my two passions: writing and programming. My computer time was pretty evenly split between writing fiction and programming with GW-BASIC. (Even as a kid, I was never that interested in computer games, although I did become addicted to Sid Meier’s Civilization for a while.)
Have you ever wondered why children seem the most acclimated to technology? Give a kid a new gizmo, and he can likely figure out how to make it work before an adult. I think the main reason for this is because children have yet to been programmed that there is a right and a wrong way. They haven’t been taught to feel shamed if they do the wrong thing, or embarrassed if they make a mistake. So they just start trying different things. They don’t worry if pushing these buttons will cause an error message to appear, they just try it and see what happens.
I’ve always believed that the best way to learn is by doing, and that’s the philosophy I’ve had when learning about computers and programming myself. I learned programming, in large part, by building applications. I’d pester my dad, asking him what programs he needed, and then I’d set off to create them. Through junior high and high school, I wrote programs for friends, for my dad’s business, and for other small businesses in the area. I didn’t always know how to solve a problem when I sat down at the keyboard, but I think that’s what attracted me to computer science – the problem-solving aspect of it.
So one important lesson I’ve learned is simply “do.” Another important lesson I’ve learned is that you don’t always know the answer to a problem, but don’t let that stop you. Answers aren’t intrinsically known, they’re discovered. These are two philosophies I’ve tried to carry from my personal experiences into the books and articles I’ve authored, especially those writings intended for beginning programmers. Beginners, understandably, are apt to feel overwhelmed when learning a new programming language or technology. There’s so many things to learn, so many ways to do something, and so many ways to do something wrong!
Poor authors can easily make a beginner feel overwhelmed; the sign of a good author is his ability to distract the reader from his innate concerns of the technology’s difficulty and complexity. This is done by showing the reader how to do something, anything. My dad, when teaching my GW-BASIC, wrote a program from start to finish, as I watched. Afterwards we discussed how the program worked, what the syntax meant, and so on. This approach not only held my interest, but allowed me to pick up the language quicker because I was able to put its syntax and semantics into context. Contrast this with an approach too many technical authors take: instead of creating a program, my dad could have sat me down and started enumerating the build-in functions, the many control-flow constructs, the concept of data types, and other technically valid, yet overwhelming pieces of information. Thankfully my dad did not choose this approach, as it would have likely killed my interest in computer programming altogether.