Is it just me, or were so many books from this era just outright bad?
I spent a few years teaching at General Assembly, and in that time I learned so much about pedology, how I often learn, how others learn, and that I can't always assume the way I learn will be appropriate for others, particularly in text format.
I had Teach Yourself Game Programming in 21 Days, by Andre LaMothe when I was an early teen. I made repeated attempts at learning game programming with it, finding only failure each time. Maybe I wasn't cut out for programming? I put it away, and went to school for music instead.
Years later, no thanks to this book, I'm a pretty good programmer. I've looked over it again, and I'm aghast at what I see. It bills itself as needing no real experience. It jumps from "this is a mouse" in chapter 1, to some pretty advanced VGA screen manipulation between chapters 2 and 3. Loops, functions, OOP, data types? Nah - it just throws code at you without concepts. It is shocking if anyone learned from this. I was worse off having read it, and nearly 30 years later kinda salty about it!
I'm good at learning from books too! I taught myself Ruby after reading _why's poigiant guide, Agile Development with Ruby on Rails, the Pickaxe book, POODR, and the Ruby internals book. If a book structures information well, and I can sit and work on practice problems, I can get the concept.
Maybe we learned a lot about how to write programming books around this era? I've generally found books on O'Reilly, Addison-Wesley, No Starch Press, etc to be rather good. They generally consider how to structure learning and information in a way that is progressive and don't make too many leaps. These "Learn in X days" style books in the 90's were basically info dumps, and without Google it was nearly impossible as a kid in the 90's to get help. No adults around me had any idea, and if it didn't work - it didn't work.
I'm curious what the breakthrough was, or what changed. The first decent programming book I ever read was Programming Perl by Larry Wall. I came to it much later, but the ANSI C book made a ton of sense upon first read too.
A good modern intro to game development (and Rust) can be found with Hands-on Rust: Effective Learning through 2D Game Development and Play. It doesn't dive deep into the more difficult parts of Rust, but it also doesn't make you feel like an idiot.
For a look back at 90's games, the Game Engine Black Book: DOOM by Fabien Sanglard really helped me understand the systems and logic of Doom and other similar games.
I agree that many books were bad simply because the authors could not write well and had no idea about pedagogy. I think the number of people who knew something about a particular subject was just smaller and that's why it wasn't questioned much by the publishers.
Another reason may be the fact that a lot of information could not yet be found on the Internet. That is why some authors were more interested in listing the information than in pedagogical communication. The result were books like "Chapter 1: How to start the compiler from command line", "Chapter 2: List of all functions of the standard library", no chapter 3.
Agreed. I think many of these books were written by people who knew the subject themselves, and were just putting their knowledge on the page without much of a feedback and testing loop to see if it was using a method that transferred to a person who didn't already have that knowledge.
Also, far too much simply typing out code that was unexplained or had no basis in prior text to the learner.
I spent a few years teaching at General Assembly, and in that time I learned so much about pedology, how I often learn, how others learn, and that I can't always assume the way I learn will be appropriate for others, particularly in text format.
I had Teach Yourself Game Programming in 21 Days, by Andre LaMothe when I was an early teen. I made repeated attempts at learning game programming with it, finding only failure each time. Maybe I wasn't cut out for programming? I put it away, and went to school for music instead.
Years later, no thanks to this book, I'm a pretty good programmer. I've looked over it again, and I'm aghast at what I see. It bills itself as needing no real experience. It jumps from "this is a mouse" in chapter 1, to some pretty advanced VGA screen manipulation between chapters 2 and 3. Loops, functions, OOP, data types? Nah - it just throws code at you without concepts. It is shocking if anyone learned from this. I was worse off having read it, and nearly 30 years later kinda salty about it!
I'm good at learning from books too! I taught myself Ruby after reading _why's poigiant guide, Agile Development with Ruby on Rails, the Pickaxe book, POODR, and the Ruby internals book. If a book structures information well, and I can sit and work on practice problems, I can get the concept.
Maybe we learned a lot about how to write programming books around this era? I've generally found books on O'Reilly, Addison-Wesley, No Starch Press, etc to be rather good. They generally consider how to structure learning and information in a way that is progressive and don't make too many leaps. These "Learn in X days" style books in the 90's were basically info dumps, and without Google it was nearly impossible as a kid in the 90's to get help. No adults around me had any idea, and if it didn't work - it didn't work.
I'm curious what the breakthrough was, or what changed. The first decent programming book I ever read was Programming Perl by Larry Wall. I came to it much later, but the ANSI C book made a ton of sense upon first read too.
A good modern intro to game development (and Rust) can be found with Hands-on Rust: Effective Learning through 2D Game Development and Play. It doesn't dive deep into the more difficult parts of Rust, but it also doesn't make you feel like an idiot.
For a look back at 90's games, the Game Engine Black Book: DOOM by Fabien Sanglard really helped me understand the systems and logic of Doom and other similar games.