Check out this post on the Head First C# forum. One of our readers, Styrkar, wrote a really neat program that takes any text and turns it into a nifty little animation. He did it as a way to extend the Space Invaders Lab to make a cool animation for the “Game Over” text.

Okay, I just want to say how cool that is. When we wrote Head First C#, one of our goals was to give readers a starting point for their creativity. I figured we’d see a few little modifications to the programs in the book. But seeing stuff like this… well, it’s just really amazing to me. Not only is this a cool program, but the code is really good. It’s readable, efficient, and easy to follow. And it’s even well-encapsulated — it’s good object oriented design! I really hope Styrkar gets the rest of the lab finished — I can’t wait to see how it comes out.

Well, we didn’t see this coming. Check out what Tim O’Reilly says in his latest blog post:

I was probably most surprised when I saw Programming WCF Services on our list of top performing books for the year. If you’re steeped in open source, you might never have heard of Windows Communications Foundation, Microsoft’s approach to building SOA applications on Windows. And you might not care. But you’d be making a mistake. Don’t count Microsoft out of the Web services game yet! They still have a brilliant, passionate developer community, and as a company have tremendous resources, persistence, and talent. And now that they have real competition, I expect them to reinvent themselves. (For that matter, Head First C# was the top selling programming language title in Bookscan last week, except for “Javascript: The Definitive Guide”. And C# continues to gain significantly on Java in terms of book sales.)

Wait, what? Let me repeat that for you. Except for a book on Javascript, Head First C# was the top selling programming language title in Bookscan last week. That’s pretty amazing to me, because we only released it at the end of November, so word of mouth hasn’t even gotten a chance to spread yet.

We took a few risks with Head First C# — we took an approach that was somewhat different than any other programming book I’ve seen. I’ve learned at least a dozen and a half programming languages over the years, and I followed the same pattern every time: I thought of a project that I wanted to do, then I figured out how to do the project using the new language. (Like back in 1994 or so, when I wanted to learn Perl and also learn about web servers, so I built a web server in Perl.) But I’m definitely not unique in this approach: pretty much every good programmer I know takes the same approach to learning a new language or technology.

Which is why I thought it was so weird that I couldn’t even find a language learning book that asked you to solve programming problems. I’ve seen a lot of “hands-on” work, where you follow step-by-step instructions to type in code to get a certain result. And certainly, an enterprising person can definitely learn that way. (If they couldn’t, nobody would buy programming books!) And certainly, we have a lot of that in Head First C#. But I just don’t think that’s enough.

I guess I have a hidden agenda here. I’ve led a lot of programming teams over the years. In 2006 and 2007, I spent a lot of time working with a consulting company, and one thing you learn working with consulting teams is that you need to work with a lot of different people. Often, you’ll have at least one very junior member on a team. And what I’ve found is that a lot of really junior developers have the capacity to be good programmers, but don’t have any experience independently solving programming projects on our own. So I decided early on that one goal of Head First C# would be to give people that experience. I wanted to teach them how to solve programming problems, rather than just follow step-by-step instructions. In essence, I wanted to create programmers who I’d be happy to have on my team in the future. (Does that sound too self-serving? I hope not!)

So when Jenny and I started working on Head First C#, it took us a few chapters to figure out exactly how to do that. It was interesting going back to the beginning of the book after we finished, to do a second pass and incorporate comments from our (really great, and really patient) tech reviewers. It really did take us about five or six chapters to work out a good way of assigning problems. We ended up co-opting the “Exercise” element that you’ll find in the other Head First books. The Lose Weight Exercises in the other Head First books were generally pencil-and-paper oriented, although I think I remember a few step-by-step programming ones as well. That’s definitely the approach we took in Head First PMP, and it worked really well.

But with Head First C#, we took the “Exercise” element in a totally different direction. We basically used the Lose Weight Exercise to give a programming assignment, where we’d give a problem to solve. We’d include a screenshot, define some classes, maybe give a little of the code, and then leave it up to the reader to build working software. It was lucky that I spent so much of my career writing specifications, because I think we really had to push our writing skills to the limit. It’s far too easy to write an Lose Weight Exercise that’s ambiguous or hard to follow… and as we found out during the tech review, it’s really demoralizing to run across a poorly-written Lose Weight Exercise. And we had to be clear that there’s no single, “correct” solution to the exericse: if it works, then you got it right. I’d be surprised if a single reader comes up with exactly the same solution that we did on any of the projects in the last third of the book.

I hope that interactive approach is what’s paying off. Word of mouth is just starting to get out, and I’m really happy to say that it seems to be positive.

One of my favorite things about Head First C# is that Jenny and I ask our readers to do a whole lot of coding. When we started doing research for the book, one thing that really struck me about other books to help you learn C# was that I couldn’t find any book that actually asked its readers to write much code. There were one or two that we saw which had some written Lose Weight Exercises. And that’s great for a textbook, but I don’t know any programmer who learned to program with a pencil and paper. If you want to be a good programmer, you need to write a lot of code. Coding is a skill, and like any other skill it takes practice. And there are a lot of concepts that just don’t “click” until you write software that uses them.

I know that when I need to learn a new language, the first thing I do is come up with a project for myself. Like when I needed to learn Perl back in 1994 or so. I also wanted to learn about how web servers worked (they were newfangled and mysterious at the time), so I wrote a simple web server in Perl. (It turns out that it only takes about 50 lines of Perl to write a very simple HTTP/0.9 web server… probably a lot fewer, if you’re an insane Perl optimizng type.) So we decided from the beginning to make sure Head First C# has plenty of opportunities for our readers to write code. Which meant coming up with projects… a lot of projects.

Which turned out to be harder than it sounds. The instructions for the project needed to be completely self-explanatory. It’s not like an Agile project, where the programmer can talk to the customers and the software can go through several iterations. No, every project needed a complete specification, one that the reader could understand completely and build exactly the software we asked for.

And that’s where video games came in really handy.

When you ask someone to write, say, a business application, you need to explain all of the details of the business. And you need to explain why the program is needed, especially if the programmer doesn’t really have any background in that business. If a programmer doesn’t understand the reason or rationale for a particular feature, then it’s almost certain that he’ll build something other than what you’re asking for. (That’s why I always like including a rationale section when I write use cases. It prevents a lot of problems later in the project.)

Video games come “pre-loaded” with their own rationale. Nobody ever needs to ask why you’d write a video game — you do it because they’re fun. Everyone already knows why you’re writing it. It’s not hard to make a video game intuitive. One easy way to do it is to model it after a game that already exists. We have one Lose Weight Exercise where the reader builds a Go Fish! game, where the player plays against two computer opponents. One project is Hide and Seek — the player searches through a virtual house to find an opponent who hid in a random place. We’ve got a dungeon game, a Whack-a-Mole game, and my personal favorite (and the final project in the book), Space Invaders.

There are plenty of other sorts of projects, too. Our goal was to get the readers coding from the very beginning, and keep them writing code through the whole thing. We designed the projects to be satisfying and fun. And we’ve already gotten feedback from readers who definitely enjoyed them.

Head First C# Labs — The Contest

We’re running a little contest for our readers. We’ve included three labs in the book where the readers build larger projects. We give them a lot of design, but we don’t actually give them the code for the solutions (like we do for all of the smaller projects). Eventually, we want to post executables for the labs. But we don’t want to post our own — we want to post executables that our readers came up with! So we’re running a contest to see which readers can send in executables first. The first person to send us working code for the lab will have their executable posted on the website as the official solution, and we’ll send them some sweet O’Reilly swag, too.  Here’s the contest page — we’re looking forward to seeing what our readers come up with!

UPDATE: This contest is closed, but check out the Head First C# forum for a new challenge with prizes!