Charles Petzold

In my blog entry two days ago, I certainly didn't mean to denigrate Adam Nathan's remarkable and enlightening WPF book. My target instead was Jeff Atwood's characterization of what a proper programming book should be. I know how long it takes to write a book, and how much pain is often involved, so I would surely be evil if I were to dismiss an entire book like Adam's with so few words. If my comments were interpreted that way, I deeply apologize.

Judging from Mr. Atwood's blog and his discussion of books on .NET Rocks, he certainly seems to like books and enjoy reading them, so it's a mystery to me why he couldn't actually discuss the content of my book rather than the fact that it's mostly black ink on white paper. It felt like a hatchet job, and a superficial one at that.

I found Don Box's take on the subject quite interesting. Don's criticisms of my book and my assumptions in writing it go very deep but obviously come from a perspective of wisdom and affection.

I know firsthand how much the book market has changed. The sales on my WPF book are a tiny fraction of the early sales on my first WinForms book just six years ago. Since my entire income comes from book royalties and magazine articles, I feel these changes quite acutely.

I know some of the problems, of course: There are so many programming platforms and APIs today that the programmer book market has become very fragmented. In the early 90s, DOS programmers really had to get into Windows programming; I'm sure there are many programmers who will never need to know WPF. Programmers want to get up to speed on new platforms very quickly and really can't afford to tackle books that take them through the material in a comprehensive manner. There are also many more resources available today for picking up information. (I can't tell you how many times I've entered a class or property name into Google.) And part of the problem is the subject matter: I've continued to focus on Windows client programming rather than branching out into Web programming, which is obviously where much of the action is nowadays.

(Undoubtedly another factor contributing to crummy book sales is BitTorrent, but that's so painful an issue I can barely bring myself to discuss it.)

So yes, Don, when I say “I know what I'm doing. I've been writing books like this for 20 years”, obviously that's not entirely true! Otherwise I'd be rolling in the big bucks and wouldn't care what Jeff Atwood had to say.

Is Applications = Code + Markup too long? As I was planning the book and writing it, I tried to keep each chapter fairly short and focused. (I didn't entirely succeed, of course, particularly with the chapter on animation.) In the back of my mind, I felt that each chapter could be tackled in one day — not necessarily a full day, but part of the day dedicated to learning WPF. Thus, the book would be completed in 31 days. This is not something I've talked about because I hate the idea of books with titles like Learn Brain Surgery in 14 Days!, but this concept certainly guided my structuring of the book.

So to me the question becomes: Is 31 days too long to learn the next major Windows programming platform, and learn it in a way where you feel comfortable coding in either C# or XAML, and you really understand a lot of the nooks and crannies? And does it really matter whether you begin with XAML on Day 1 or Day 19?

I keep coming back to the content: I have packed Applications = Code + Markup with a wealth of information and code examples. I am very proud of this book, and it is quite distressing to see it trashed because it doesn't have pictures or color, and because I've written successive pages of coherent prose without chopping it up into boxes and sidebars.