On Books (WPF and Otherwise)

Someone pointed me to the coding horror comparison of Charles Petzold and Adam Nathan's books on WPF.

It’s painful on many levels to read both it and Petzold’s reactions to it and other criticisms.

With respect the books themselves, I’ll hide behind “professional courtesy” and not violate the “books authors don’t criticize other people’s books” commandment that I learned (painfully) from Bob Orfali.

With respect to the blog posts however, Charles does make two points that I feel compelled to react to.

On XAML

A lot of people comment on the paucity of screen shots/images in Petzold’s book. I think this one is cosmetic and Charles himself has admitted he wish he had more of his. This one is trivial to fix in a 2^nd edition if Charles really wants to change it.

Where I think Charles and I disagree is on the use of XAML, which Charles manages to postpone using until page 457.  Here’s Charles’ explanation from his blog:

But I'd still structure the book the same way because I think my coverage of the C# API and the WPF intrastructure provide an excellent foundation for eventually incorporating XAML into your WPF applications.

The notion that looking at WPF through the lens of C# rather than XAML is somehow more “foundational” or “deep” is missing the point. 

Except for input/event handing, pretty much the whole WPF enchilada adheres to the “markup equals object model” mantra.

As a WPF user, I spend at least as much time reading and writing XAML as I do reading/writing C# code that does WPF-isms. I do spend a lot of time in C#, but little of it is WPF specific, which arguably is one of the strengths of WPF’s data/content facilities.

In my opinion, the sooner folks get thrown into the XAML pool the sooner they learn to swim.

On Books

The broader point Charles makes reads on the role of the technical book in circa-2007 programming, and on this one, I think Charles and I are again at odds.

Charles’ statement that “PowerPoint has won” is in my opinion the wrong conclusion to draw from the data at hand.

Unlike the book writing period of my life, my job now is focused on producing software that helps my employer make more money. 

I think that makes me the prototypical customer for books like Charles and Adam write.

Here’s what I can state about being on the “consumer” end of the book transaction:

If a given technology is tangential or a detail to my getting my job done, I won’t buy a book. Period. End of story. What I will do is spelunk the technology using Reflector, even if I have source access. I’ll also scan the web using my search engines of choice and then spend 30 minutes or so harvesting the results.  On this kind of task, I’m pulling together the narrative in my head as I go.

If a given technology is central to what I’m building, I’ll buy many books on the topic based on the principle that I will opportunistically glean value from them at some point.  

My general selection process is based on publisher. Addison Wesley and Morgan Kaufmann are tops for certain kinds of problem domains. O’Reilly and Pragmatic Press are tops for other domains. If it isn’t one of those four publishers, I probably won’t buy it.

So, given the stack of books I just picked up, which one do I read? That’s easy: I’ll read the shortest book on the topic.

Let me repeat that.

I’ll read the shortest book on the topic.

Here are my reasons.

1.      I have limited time and want to optimize my spend. This is simple time management, plus I’m impatient (ask anyone who has to converse with me).

2.      I find that most O(1000) page books are that long because the author didn’t do his/her job of eliding unnecessary detail and/or included a variety of topics that aren’t central to getting the gestalt – that is, topics that would fall into my “surf the web and spelunk in reflector” category of technologies.

3.      Often, a short book reflects the author having done more synthesis and distillation up front and will often yield a more “to the point” and insightful book.

This isn’t about me wanting PowerPoint.

This is about me wanting the most time-efficient way to deeply understand a technology so that I can do a better job producing software that helps my employer make more money.

Having to wade through thousands of lines of superficial/tangential C# code in a book rarely if ever satisfies my efficiency or depth requirements. Unlike some of Charles’ critics, I don’t need a lot of figures either, although UX technologies like WPF certainly requires more than say a book on LINQ or SQL Server would.

Where are we?

Charles states “I know what I'm doing. I've been writing books like this for 20 years.”

The interesting question in my mind is how much or little today’s programming profession resembles the one that existed when Charles’ first book made such an amazing impact.