It all started around 2002 when I was contemplating teaching programming. Ruby struck me as an excellent language for beginners. While Ruby was gaining traction for its power, elegance, and overall fun factor among experienced developers, I felt it had untapped potential as a first programming language for newcomers.
However, beginner-friendly Ruby documentation was scarce back then. Discussions within the community revolved around crafting a “Ruby for Newbies” tutorial and, more broadly, effective methods for teaching programming itself. The more I considered these aspects, the more ideas I generated – somewhat surprisingly to myself. Eventually, someone suggested, “Chris, instead of just talking about it, why don’t you actually write the tutorial?” And so, I began.
My initial attempt wasn’t great. The ideas seemed solid in theory, but creating a truly effective tutorial for individuals with zero programming experience proved to be far more challenging than anticipated. It seemed adequate to me, but I already knew how to program!
What truly improved the tutorial was making myself readily accessible for feedback and consistently assisting learners when they encountered difficulties. Observing recurring stumbling blocks allowed me to identify areas needing revision. Through iterative rewriting, driven by user feedback, the tutorial gradually improved.
Years later, around 2004, it had reached a point where I felt satisfied with its quality. It was even good enough that I considered it complete and was ready to move on to other projects. Serendipitously, an opportunity arose to transform the tutorial into a published book. Given that the tutorial was largely finished, I assumed this would be a straightforward process – just some minor polishing, additional exercises and examples, perhaps a few extra chapters, and reviews from a larger audience.
It took another year of work, but the resulting book became truly excellent, largely thanks to the invaluable contributions of hundreds of brave learners who helped refine it.
The content available on this website represents the original tutorial, largely unchanged since 2004. For the most up-to-date and enhanced version, I recommend checking out the book.
Thoughts For Educators: Guiding Principles in Programming Education
When teaching programming, or guiding someone on their journey into coding, certain principles can significantly smooth the learning curve. Programming is inherently challenging, so effective teaching methodologies are crucial. These are some guiding ideas that I found helpful:
Firstly, concept separation is key. I aimed to isolate concepts as much as possible, ensuring students tackled only one new idea at a time. Initially, this was tricky, but with practice, it became almost too easy. While some concepts naturally precede others, I was surprised by the limited inherent hierarchy. Ultimately, I chose a sequence, prioritizing an order where each new section felt motivated by the preceding ones.
Secondly, teaching one primary method simplifies learning. For programming novices, learning one way to accomplish a task is significantly easier than navigating multiple options. More importantly, limiting the initially taught methods fosters creativity and problem-solving skills. Since programming heavily relies on problem-solving, encouraging this at every stage is paramount.
Thirdly, piggybacking on existing intuition is powerful. I tried to relate programming concepts to ideas learners already understood. Object-Oriented Programming (OOP) lends itself well to this. I subtly introduced terms like “objects” and “kinds of objects” early on. I didn’t overwhelm beginners with definitions like “everything in Ruby is an object” or “numbers and strings are object types,” as these are initially meaningless to newcomers. Instead, I discussed “strings” (not “string objects”) and occasionally referred to “objects” simply as “the things in these programs.” The fact that these “things” are indeed objects in Ruby allowed this subtle introduction to work effectively.
While avoiding unnecessary jargon, I prioritized accurate terminology. When a specific term was necessary, I used the correct one from the outset to prevent relearning later. For example, I used “strings” instead of vague terms like “text,” and “methods” for actions associated with objects.
Finally, engaging exercises are vital. I dedicated considerable time to crafting fun and interesting exercises. Uninspiring exercises can quickly kill motivation, while well-designed exercises create an irresistible urge to solve them. Investing time in developing high-quality exercises is essential.
About the Original Tutorial’s Creation
The tutorial pages (and even this page) are generated by a substantial Ruby program. Importantly, all code examples were automatically executed, and the displayed output is the actual generated output. This approach is the most effective, easiest, and coolest way to ensure code examples function exactly as described. Users can be confident that there are no errors in copying outputs or untested code snippets – everything has been rigorously tested.
Acknowledgements
I want to express my gratitude to the ruby-talk mailing list community for their insightful feedback and encouragement. My sincere thanks go to my wonderful reviewers, whose help significantly improved the book. Special appreciation to my dear wife, who served as my primary reviewer, tester, guinea pig, and muse. Thank you to Matz for creating the fantastic Ruby language, and to the Pragmatic Programmers for introducing me to it and for publishing my book!
If you find any errors or typos, or have comments, suggestions, or interesting exercise ideas, please let me know.
