Andrew Stellman: The challenge of challenging the learner

By Caitrin McCullough

Here's another from Andrew Stellman, coauthor of Head First PMP and Head First C#.

In my last post, Pushing the Interactivity Envelope, I started talking a little bit about the exercises in Head First C#. We gave our readers lots of exercises—programming problems and puzzles that let our readers "stretch" their programming "legs" and solve problems independently. Well, it turns out that when it came to actually writing the exercises, we found that creating exercises for our readers was one of the toughest, most time-consuming things we did. That may seem a little odd; you'd think that the hard part is teaching the material, and that the exercises are just there to help you apply what you've learned. That's basically how I thought about it when we first got started writing the book. But it didn't stay that way.

When we started, we set out a few ground rules when we started building our exercises. The first one was that there's no such thing as cheating—we encourage readers who get stuck to peek at the solution. It's really easy to get caught up on something simple, and it's very hard to learn when you're frustrated. But the thing about those solutions is that there's an unlimited number of ways to solve any programming problem. So that led us to our second ground rule: it's absolutely fine if a reader comes up with a different solution than we did. In fact, there's a good chance that some of our readers came up with better solutions. (In fact, we've seen posts on the Head First C# forum from readers who did!)

Things went pretty smoothly for a couple of chapters... or so we thought, anyway. But as we got through the first third of the book, the exercises became harder and harder to write. The programs were getting more complex, and we needed to give our readers some pretty specific instructions. When you've got a program with a lot of moving parts, it's very easy to write instructions for an exercise that are very difficult to follow.

Not only that, but we had an especially difficult (and entirely self-imposed) exercise-writing challenge: giving our readers an exercise with a trap to fall into. Here's an example. The best way to understand why encapsulation is useful is to understand the kinds of problems you can run across if you don't use it. You can see how we handled this if you take a look at the beginning of the Encapsulation chapter (Chapter 5 [pdf]), where the reader builds a program to help Kathleen, a party planner, estimate how much to charge for a dinner party. It seems like the program is working just fine. But once Kathleen uses it, she finds out that it doesn't work the way she thought! It turns out that the program has a bug, and the way to fix that bug is to use good encapsulation (which is what that chapter is about). So that was a big challenge: how do we come up with an exercise where the reader unknowingly builds a specific bug into the program? And how do we do it without making the reader feel like they made a mistake?

Those were big questions, and we weren't sure we'd pulled it off until the technical review. Our review team included several people who didn't know C# and would use our book to learn it. You can imagine how happy we were when our tech reviewers built the program exactly the way we'd intended, and ended up with programs that had exactly the bug we'd wanted them to include! It was definitely a relief.

Unfortunately, that relief didn't last long. As the tech reviewers moved on in the book, they started having more trouble with later exercises. When we got their feedback and went back through our exercise instructions, we found that there were all sorts of ambiguities and problems that we'd left in. Remember the beehive management program I'd mentioned in my last post? Well, it turns out that the instructions were extremely difficult to follow, and some of our tech reviewers got stuck and had to skip the exercise entirely! Ugh.

What we realized—and probably should have known from the beginning—was that coming up with a lot of projects means writing a lot of requirements that the reader needs to meet. And one thing about requirements that becomes really clear when you have a lot of small projects is that people have a lot of trouble figuring out how to build your program if they don't understand what it is the program needs to do. Every program is written to solve a problem, and the programmer needs to understand that problem. And that was the problem with the beehive program: it wasn't 100% clear exactly what the reader was supposed to build. When they flipped to the solution, they'd basically think, "Wait, I was supposed to build that?"

That's actually a classic programming problem: how to get your programming team to build exactly what you want them to build. Jenny and I have written pretty extensively about requirements gathering and using great practices like use cases, reviews and iteration to solve those problems (like "Kitchen of the Future," a post I wrote last year about one of my favorite requirements pet peeves).

Luckily, there's an easy solution: have our readers write games. A game solves a very straightforward problem: the user is bored, and needs entertainment. Also, people expect games to have rules, and are good at anticipating how a game is supposed to work. So we have the reader write a bunch of games. Some of them are really simple, like a Whack-a-Mole game where they have to click the button as soon as it turns red. Others are more complex, like a Go Fish game or a Hide & Seek where you explore a virtual house to find an opponent who's hidden himself in a random place.

It's easy to communicate the requirements for a game, because readers already come to the table understanding so much about the program they're about to write. So by the time readers are done with Head First C#, they've written a whole bunch of games... which, in my opinion, is really cool and extremely satisfying.

 

 

Comments

---

 

Post a comment:

Name

Website

Save?

Email Address (required)

Comments