Home About Eric Topics SourceGear

2007-04-30 13:19:55

In defense of Petzold's WPF book

Last week, Jeff Atwood blogged about two WPF books:

Atwood likes the Nathan book a lot more than the Petzold book:

The difference in approach is immediately obvious to anyone who opens both books. One looks compelling, fun, and inviting; the other looks like a painful, textbook slog that's the equivalent of writing code in Notepad. Petzold's an excellent writer, but writing alone can't make up for the massive layout deficiencies of his book.

I am writing this blog entry to throw in my two cents on behalf of Petzold's book and his writing style.

But first let me say that I like "Windows Presentation Foundation Unleashed" very much.  It's an extraordinary book.  Nothing I say here should be interpreted as a criticism of Adam Nathan or his work.

Deep Understanding

I see the market for developer books following the same path as the market for developer tools:  There is an increasing priority on "quick results".

Modern development environments like Visual Studio include many features which are specifically designed to improve developer productivity:

These features work!  As I noted last week, it is amazing how quickly we can get raw code working with Visual Studio.

I am as addicted to IntelliSense as the next guy.  But I do believe this stuff come with a tradeoff.  To some extent, the increasing emphasis on getting quick results comes at the expense of "deep understanding". 

I define deep understanding as the knowledge of how stuff works "under the hood".  For example:

I believe that deep understanding is still very important.  Today's frameworks and libraries are providing some very level high abstractions.  This is good.  It helps us work faster.  But even well-designed APIs are not perfect.  Sometimes an abstraction layer covers up a problem that is happening at a lower level.  Now you're in trouble, but you can't see why.  (Joel Spolsky refers to this as a leaky abstraction.)  Deep understanding helps you get you out of this mess.

Basic API knowledge will help you write raw code and get quick results.  Deep understanding will help you get out of trouble.  When I hire a software developer, I look for deep understanding.

Petzold's Books

I would characterize Petzold as a writer whose primary goal is to help his readers gain deep understanding.  Grab a Petzold book and take the time to actually read it.  It may surprise you how much you learn.

Charles Petzold is currently writing a book on WPF 3D.  I am helping him as a proofreader (without compensation -- there is no conflict of interest here).  I recently sent back one of his chapters with my usual list of typos and minor edits.  He responded and said, "Fine, but did you learn anything?"

What an excellent question!  In fact, I did learn something by reading that chapter, and this is evidence to the quality of the content.  I am an experienced user of WPF 3D, but when I took the time to carefully read his material, I still found it very educational.

(And BTW, for those of you who wish that Petzold's first WPF book contained more figures and illustrations, do take a look at his 3D book when it comes out.  It looks to me like it will have a lot of pictures illustrating the concepts.)

For the disciplined and patient software developer who wants deep understanding, Petzold's books are still the way to go.  The fact that such developers seem to be the minority today is a problem with our industry.  I like quick results, but if we continue to sow less and less deep understanding, we will end up reaping a lot of problems.

Rude Preemptive Responses to Comments

"How dare you say that Adam Nathan's book offers nothing more than a shallow coverage of the topic and inhibits deep understanding?!?"

RTFBE.  I didn't say that.

"How dare you say that it's impossible to write for deep understanding and still have a pleasing visual layout?!?"

RTFBE.  I didn't say that.

"How dare you suggest that most of today's developers are too undisciplined and impatient?!?"

RTFBE.  I didn't say that.

Oh, wait.  I guess I did say that.

Either way, I think it's true, but that doesn't automatically mean that the blame falls where you might think.  Here's your homework assignment:  If you would agree that many of today's developers are undisciplined and impatient, spend 5 minutes thinking about why they are the way they are.  :-)