The art and science of choosing textbooks

Even after 11+ years of teaching, I find that selecting textbooks for a class is much more of an art than a science. Sure, I can apply “scientific” principles to selecting a textbook—evaluating how certain key topics are covered, weighing the ratio of code to theory, vetting the explanations and examples—but in the end, I never quite know how my choice will go over. In the best case scenario, I identify a book that both my students and I like and find effective. But honestly, if I can at least identify a book that we can both tolerate, I count that as a win. Sometimes, even with my careful selection process, I get things wrong. And sometimes, a book that’s worked wonderfully in the past falls flat with the next group of students.

I found myself in that last situation last spring, when I taught Software Design.┬áIn the past, I’ve used a particular textbook for the design patterns portion of the course. I like this particular book a great deal: it’s irreverent and clever, but most importantly, it presents each design pattern through the lens of an extended example, coded up in Java. In the process of developing the example, the students see a lot of code, and are also introduced to the pitfalls and common variations of each pattern. The students also see examples of each pattern in practice, giving them context for the usage of each pattern.

Last year, for the first time, my Software Design students complained about this textbook choice. Loudly. They hated this book. It’s too long, they said. It’s too condescending, they said. It lacks gravitas, they said. (OK, they didn’t say exactly that last one, but that was the gist of the criticism.) Basically, they wanted a textbook that was more textbook-y and less over the top.

I’ve refrained from assigning the Gang of Four design patterns book in the past. Not because I don’t like it—on the contrary, it’s a fabulous reference book, and I do use it often in my own work. I don’t assign it because the usage examples are rather sparse and there isn’t a lot of code in the text. I just wasn’t convinced that it would work in my class. But, since the criticism was so strong last time around, I decided to give it a go this time around and see if I had better success.

The verdict? This text hasn’t worked well at all for this group of students. As I suspected, the students are having a lot of trouble figuring out when or why to use each pattern. The lack of examples and lack of code is negatively affecting their comprehension. (And the few examples in the Gang of Four? My students don’t find them convincing.) I’m having to do a lot more PR work in class to get them on board with the concept of design patterns. I’ve spent almost all my class time in this part of the course lecturing (lots and lots of lecturing, which I typically try to avoid) and walking through examples, when normally I’d set up an example, walk through part of it, and leave the rest to my students to develop, so that they get some much-needed practice with the patterns.

Next time I teach this course (which, sadly, won’t be for at least 2 years), I will go back to the Head First book. I do think some of the criticisms from last year’s students are valid, but if anything this term’s experience has underscored just how important good, extensive code examples are in learning a difficult concept or set of concepts. This experience has also helped solidify in my mind why I choose to use this book, and I’ll be able to make a stronger case for it with the next batch of students.

Now, if I could just find a Data Structures textbook that I don’t absolutely abhor….

 

Advertisements