Written by: steve ross on January 21st 2008
Nope. This is not an ad for some technical school. Fooled you, huh? This is more about the technique of learning to program. In the olden dayes when computers had core memory and dinosaurs still roamed the earth, there was a high cost associated with computing cycles. So, people who burned those cycles were selected from the (about) 7 who knew how to write code.
Now the cost of computing cycles has dropped asymptotic to zero, and everybody is a programmer. Right? Well, not so much. Even though the barrier to entry has dropped dramatically, the fact still remains that some people know how to write code and some don't. If you're in the latter category but want to transition to the former, you have to learn how. Let me suggest a few really obvious ways to fail:
- Pick up a book called "[anything] for Dummies" and start reading. Won't work. Programming is not for dummies.
- Pick up a book about something complicated, start typing in their code and become frustrated when you don't understand the errors you're getting.
- Join a mailing list and ask 100 questions at once.
These might seem like, duh, simple observations, but observed behavior shows that these are patterns people repeat and wonder why their success rate is so poor. Let me finish venting about the "Dummies" books. I don't just hate them. I feel any book on computer programming, nuclear physics, cellular genetics, etc. that contains words like, "made easy" or "quick start," is just insulting. These are serious pursuits. Heck, I probably wouldn't even buy "Quilting for Dummies," and I have no idea whether smart or dumb people make quilts -- I just don't think I'm a dummy. Ok, I guess I've made my position on demeaning book titles clear.
The rest of this is a bit more complicated. There are a ton of really, really cool books out there that people with the correct level of expertise can pick up and learn from. People without that expertise will be totally lost, frustrated, or misguided. So, let's take my favorite complicated task made easy: Developing Web applications. Say you haven't really tried your hand at this programming gig, but you threw a few pages together with Dreamweaver or something like that. Yesterday in the bookstore, you happened across a book by this fellow Dave Thomas that had a title filled with all kinds of impressive buzzwords like "agile" and "web development" and even more compelling, "Ruby on Rails"! A couple of titles to the left was the book you really should have gotten - also by Dave Thomas - but no, you just had to go right out and build a Web site, right?
So you lug the book home, open it up, read the clever little intro and skim a few more pages before you realize you aren't understanding a whole lot of this. But wait, you think, there are examples in here and I can try them and all will become clear. And at that moment, you start into a spin from which you will not recover soon. You see, what you just did was to take on a programming task before learning to program.
Now, the right thing to do when faced with this situation is to head back to the bookstore and pick up "Programming Ruby: The Pragmatic Programmer's Guide," which was what you intended to get in the first place, had you just known. But that's not going to happen. First, you have to go through the other phases of being a n00b programmer.
Phase 1 - Denial: You can get this. Just work through a few more examples in the book and you'll become an expert. It worked when you learned HTML, right?
Phase 2 - Resentment: You're not getting this. Nothing works. This book isn't worth a s&!t.
Phase 3 - Blame: You've got the wrong computer. All the cool kids have Macs and that's why they write beautiful code that I can't understand. It's your computer's fault. Oh, yeah, and the fault of that guy who wrote the book.
Phase 4 - Spam: Aha! There's a mailing list. A public mailing list. How cool is that. Now, I'll just put all my code out there with a descriptive subject line like "please diagnose my error" and all those nice Open Sourcies who have nothing better to do will figure this out for me.
Phase 5 - Public Humiliation: Someone on the list finally tires of translating what that nice Dave Thomas wrote in the book into something you understand and tells you to go back and reread it until you've grasped at least one chapter.
Somewhere along this path, you get enough information to realize your quest is not about a Web site but about knowing how to program enough to build one. And if you internalize that wisdom, you'll now head back to the bookstore and buy Dave Thomas's "Programming Ruby" book (aka: Pickaxe).
I'm picking on Ruby, Rails, and most of all Dave Thomas (sorry, Dave). I should note that Dave's books are among the best I have on my shelf and when you are ready for them, read them in the right order. This could just as easily have been written about PHP, ASP.Net, or any other hot technology.
At this point, you're probably fed up with me and you might even be wondering whether I have anything positive to contribute here (or is this another one of those blog rants). I think I do. Here it is:
- Learn to walk before you try to run. If you can't make write a program to add 2 + 2, you're not a programmer. If you can't write a program to print "hello, world," you're not a programmer. You need to understand the facilities offered by the language, its grammar, and perhaps more importantly, its idioms. Don't do anything complicated until you can demonstrate to yourself that you've mastered these things.
- Learn to walk before you try to run. Even if you know how the language you've selected works, do you know how to model a simple problem using that language? For example, storing an arbitrary number of states/provinces and their associated abbreviations for quickest retrieval. Printing a sorted list of those states and provinces.
You see where I'm going with this? The first part is rote memorization of keywords and syntax, sort of like multiplication tables; the second is an application of what you've learned sort of like solving your first word problem.
So now you are a programmer. At least you read the book cover to cover and wrote some programs that work, right? Just a word about the mailing lists and forums (or is that fora?).
- Before you are tempted to post a question, be sure you have used Google or some search engine likely to succeed at finding the information. Far too many posts are answered with the advice (correct) to type a particular string into Google.
- Consider sharing your hard-won wisdom before you ask for someone else's. Some people actually won't ask a question unless they have found three they can answer first. The say they often answer their own question in the interim. In any event, no matter what multiplier you choose, the point is to give back to the community and to give yourself an incentive to figure things out yourself.
If you agree, disagree, think it's the pot calling the kettle black, or if you're Dave Thomas and think I should have picked a different example, feel free to chime in.