Preface to the Second Edition
I ran into an old friend the other day. It’s been more than a decade since last we spoke. As we were catching up, I mentioned, “Oh, and I sort of accidentally wrote a book a few years back.”
After all, I didn’t really mean to write this book. Once upon a time, some of us Ruby fans were chatting about teaching programming, and I had a few things to say about it. Not much. Just a few things.
Somehow the conversation migrated onto a wiki somewhere, and I wrote up a few of my ideas. After a while, it seemed like I was the only one writing, so I moved some of my thoughts to my own website. Suddenly I realized it was starting to look suspiciously like a tutorial.
And not a very good one, I have to say.
Well, my initial attempts seemed pretty good to me, and I got positive feedback from the other Ruby programmers who saw it. But then again, we all knew how to program. When I actually showed the tutorial to a nonprogrammer (my extremely patient wife), it was clear that there was still much work to be done.
So, I reworked it and rewrote some sections, and it became…better. Not great, though. It took several more iterations before it was really usable. But by then I was hooked: I was going to make this tutorial the best programming tutorial ever! Fortunately, it got plenty of use, I got plenty of feedback, and it continued to improve. (I could never have done it on my own. If it weren’t for all the comments and questions, this whole thing never would have gone anywhere.)
And so it went, for about three years. Conversation moves to wiki. Wiki migrates to tutorial. Tutorial becomes book. And at every step, I’m answering as many emails as I can, noting where people are having the most trouble, learning why they are having trouble, and smoothing the way for the next programmers-to-be. At every step, it’s getting just a tiny bit better.
As it turns out, 5,000 tiny bits really add up.
And now that it’s done, I’m convinced I learned more from this book than anyone else did—not about how to program, of course, but about the way we learn programming and about learning in general.
Perhaps the most important principle in teaching programming is to separate concepts as much as possible so that the programmer-to-be has to learn only one concept at a time. This is much easier said than done, though. There were just so many things that I was used to, so I often didn’t realize when I was introducing a new concept. With some practice, though, and much help from aspiring programmers, it became easier as I went along.
Naturally, I tried to cover more basic concepts before working up to more complex concepts. I was amazed, however, at how little of a precedence hierarchy there really is. Many of the ideas could be taught meaningfully independently of the others. Eventually, I just had to pick an order, and I tried to arrange things so that each new section was motivated by the previous one.
Another principle I realized early on is the importance of teaching only one way to do something. It’s an obvious benefit in a book for people who have never programmed before. For one thing, one way to do something is easier to learn than two. Perhaps the more important benefit, though, is that the fewer things you teach a new programmer, the more creative and clever they have to be with the primitive bits they do know. Since so much of programming is creative problem solving, it’s crucial to encourage this as soon as possible.
I tried to piggyback programming concepts onto concepts the new programmer already has and to present ideas in such a way that their intuition will carry the load, rather than the tutorial. Object-oriented (OO) programming lends itself to this quite well. I was able to begin referring to “objects” and different “kinds of objects” pretty early in the tutorial, slipping those phrases in at the most innocent of moments. I wasn’t saying anything like “everything in Ruby is an object” or “numbers and strings are kinds of objects,” because, beloved as they are in the Ruby community, these statements really don’t mean anything to a new programmer. Instead, I would talk about strings (not “string objects”), and sometimes I would refer to “objects,” simply meaning “the things in these programs.” The fact that all these things in Ruby are objects (in the OO sense) made this sort of sneakiness on my part work so well.
Although I wanted to avoid needless OO jargon, I did try to make sure that if you do need to learn a word, you learn the right one. (You don’t want to have to learn it twice, right?) So, I called them “strings,” not “text.” Methods needed to be called something, so I just called them “methods.”
As far as the exercises are concerned, I think I came up with some good ones, but you can never have too many. Examples were much easier: just come up with some joke that you can relate to the concept you’re explaining, and there you go! But exercises…they were hard. Honestly, I bet I spent half of my time just trying to come up with fun, interesting exercises. Almost everything I came up with was just boring, and boring exercises absolutely kill any desire to program. On the other hand, the perfect exercise creates an itch you can’t help but scratch. I did my best, but I don’t think any of them are perfect. I hope you will come up with your own programming tasks or even just variations on those given here.
I remember someone telling me that they had added a bunch of code to their orange tree program so that it would actually draw an ASCII-art orange tree! It grew as the tree got older and even displayed the correct number of oranges! That’s amazingly cool!
A lot of software grows in this way: small, simple beginnings, with tiny improvements here or an interface overhaul there, until you have something much larger than what you started with. I guess books can grow this way, too.