Andrew Stellman: How we made Head First C# different

By Caitrin McCullough

This week we're hearing from Andrew Stellman, coauthor of Head First PMP and Head First C#.

First of all, hi there! I'm Andrew Stellman, author of Head First C# and Head First PMP. My coauthor, Jenny Greene, and I will be guest bloggers here for the next two weeks. So you'll get to know a little about us, and (hopefully) a lot more about some of the things that we like to write about.

And I thought that a good way to start out our guest blogging gig would be to give you a little insight into the kind of thinking that went into writing Head First C#. Specifically, I want to tell you a little bit about how we made Head First C# different—and, I hope, better!—than pretty much any other programming book I've ever seen.

See, to me, Head First is about breaking down preexisting ideas and assumptions about what you can do in a book. I think that's best summed up in the great "I can't believe they put THAT in a ___ book!" graphic that starts out the introduction of a Head First book. We really tried to take that idea to heart when we started planning Head First C#. Jenny and I tried to ask ourselves, "What invisible box does a typical author trap himself in when he starts writing a book?"

We started looking through books about learning C#, just to see what other people do. And one thing that really seemed odd to me—I mean, seriously weird, when I really thought about it—is that everyone seems to start you out with the smallest possible program you can write. And it just seemed, well, counterproductive to do that with Head First C#. Here you are, with this really powerful IDE that makes it really simple and intuitive for anyone to design a reasonably slick-looking user interface almost immediately, and the first thing you do is build a boring little "Hello world" console application. That just didn't make sense.

So we decided to go in an entirely different direction: we started out by building a pretty complex application. And we took advantage of the fantastic IDE to make it really easy to do. Now, I know this will probably get me hate mail from some hard-core C++ programmers who think that only losers use IDEs, and that if you're not using Emacs then you're not a real programmer. All I can say in response is that I can't believe you're using a high-level language—real programmers code assembly by hand. And none of that assembler crap, either. If you're not entering opcodes directly into a hex editor, you're not really programming, right?

Seriously, though, it turns out that a good IDE is a really effective teaching and learning tool, and to be quite honest, the Visual Studio IDE is the best one I've ever used. (If you're curious, my second-favorite is IDEA, and Visual Studio borrows some of the best features from IDEA.) We were able to bootstrap our readers straight into developing pretty complex software, building a database-driven application to manage Rolodex contacts. That's a pretty satisfying way to start out the book, and it immediately gets the reader used to some basic, intuitive ideas (like bundling code into methods that are easy to call and do the same thing over and over again). Once we had that foundation, it made it a lot easier to jump into more basic programming concepts. To the reader, it feels like you're learning really quickly.

Once we started down this road, it made our jobs a lot easier because we could keep coming back to the IDE when we needed to teach concepts. For example, by the time we introduce the idea of an instance, the reader's already seen it in action: all those buttons and labels that get dragged onto forms are instances of a Button or Label class. And the idea of setting properties is already really familiar, because they've been using the Properties window all along to set properties on their UI objects. We kept dipping into that well over and over again to teach lots of different concepts.

So why doesn't everyone take that approach? I've got my theories. One reason that many authors start at the very bottom is that they feel like they can't just scratch the surface of a particular topic. If you're going to learn about something—say, clicking on a button—then you need to learn it completely, in depth: you need to learn about adding event handlers, which means that you need to learn how event handlers work, which means you need to learn about delegates, which means that you can't really learn about forms and GUI at all until you're almost done with the book. How unsatisfying!

One thing we wanted to avoid, however, is depending on the IDE as a crutch. So we had a rule from the very beginning: there are to be no mysteries in the IDE. We made it clear from the start of the book that the IDE is basically just a fancy text editor: every time you drag, drop, change or click anything in the IDE, all you're doing is altering your code. We started out by showing how changing properties alters the code, and how altering the code makes the IDE change the property. We reinforced that link over and over—changes to the IDE are just changes to the code. And you know what? The IDE itself made it really easy to reinforce this. There are many times in the book that we ask our readers to search for something—say, the new statement to instantiate a form object or the name of a button's event handler—in order to see exactly what code the IDE added for you.

The net result, I think, is that we took an IDE that seemed really complex and opaque and made it transparent. I think that a C# programmer who understands the connection between the IDE and the code has a much better foundation than one who only knows how to create console applications using a simple text editor.

 

 

Comments

---

 

Post a comment:

Name

Website

Save?

Email Address (required)

Comments