I had similar thoughts over the whole issue. Petzold's WinForms book covers terrain that few others do - I suspect his WPF book will be similar.
There is a place for both types of books. The only problem with a book that is less attractive is that it will not be read by the people who most need it.
Consider a developer who has no clue about the internals of a programming environment. Why is that? That developer is looking for maximum gain with least pain. The motivated developers will read anything, not so "many of today's developers".
Hence it is very important to create books that make the really complicated issues very simple and accessible. We do see a lot of such books for GUI programming. We need a lot more for APIs and other programming fundamentals.
Heh. I'm gonna say pretty much the same thing here that i did over on Atwood's blog, except that here it's actually slightly relevant (and waaay more metaphor-cluttered):
Petzold is a fence-sitter.
His books aren't the "ocean of technical details, ripping good yarns of obscure design decisions and their rippling effects throughout the system as a whole" tombs that tech junkies like me squirrel away in their mattresses for reading after lights-out.
And they aren't the instant-gratification "type this and get this wow ain't that cool" books beloved by harried programmers needing quick solutions to common problems on new platforms.
No, Petzold's books sit somewhere in between. They leave me hungry, and not in a "you're always half a BLT short" sort of way, where i wish they'd just gone on for *one more chapter*. More of a "hey, this BLT has no bacon!" sort of way. They're not *bad* books. There's always a lot to 'em, and i'd be lying if i said i didn't always manage to learn something. But they aren't Deep Understanding books. They're Plain Old Regl'r Understanding books.
That's why they don't appeal to the rapid-coding churn-out-something-and-move-on types, who would just as soon not bother with understanding of any sort if given the chance.
And that's why, although they may find a place on my shelf from time to time, they never end up clutched eagerly in my hand, steaming cup of cocoa in my other, as i prepare to immerse myself deeply in The Subject At Hand...
Amen. It killed me when Don Box said "I’ll read the shortest book on the topic." While this may work for Don, it kills me because I'm sure it will validate the legions of people who just skim for understanding (or worse, hit the period key and start browsing through what Intellisense is offering them). Sometimes, you have to put in the time to actually understand things: there's no substitute for hard work (or studying).
I agree with your statement that books should give you a deep understanding. It seems weird to use that argument in this context, though. The 3 examples you gave about WPF are satisfied by both books, I think. I know...RTFBE. It still seems misleading, though.
Eric, I agree with your characterization of Petzold's writing... but this blog entry really has absolutely nothing to do with Jeff Atwood's criticism which was about the _layout_, not the _content_ of the book.
You "preemptively" say at the end of your blog entry that you didn't say that "it's impossible to write for deep understanding and still have a pleasing visual layout" -- but if that's not what you meant to say, why did you introduce this entry with Jeff's well-deserved criticism regarding layout?
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. 
I was going to spend that five minutes, but I'm too undisciplined and impatient.
@ChrisNahr:
I think I am more interested in just encouraging people to look past layout and see excellent prose than I am in disagreeing with Jeff Atwood.
Warning: Rant to ensue...
While I agree with a lot of what you are saying in tihs book, especially the last point about developers moving up the stack and knowing things at a high level.
I would like to comment about Petzold's question back to you. "Fine, but did you learn anything?"
There have been very few books/chapters where I knew the content really well where I did not learn something. This is not a testament to the quality of the author but of the reader and their interest in the content. If the reader is truly interested in the content they will think and do some form active participiation (whether it's just thinking of how to apply the knowledge to actually walking through an example) and this is where the learning will take place.
While material can be presented in such a manner where this active learning and thought provoking is more easily accomplished I don't see this as the reason you learn something from the book. Take for example one of the books I have used a lot, SQL Server 2000 Internals. While this book is not visually appealing or easy to read. It does however provide a ton of good information and I have had a many thought provoking experiences while reading it. However if I recomended this book to anyone just interested in SQL Server it would be a bad idea if they don't already understand other fundamendtals.
It would be nice if more people spoke about and discussed this topic of deep understanding. I'm running into less developers who know the tool and "why" and "how" it works. Increasing constraints of deliverables also contribute to this. Good read. I might pick up his book. Haven't read Petzold since programming Win 95.
"I think I am more interested in just encouraging people to look past layout and see excellent prose than I am in disagreeing with Jeff Atwood."
But layout is important.
I've read both the books in question and Nathan's was much more enjoyable and easier to read. Don't get me wrong, I like Petzold and I learned a bunch from his book, but I had to get past the layout to do it. Poor layout hinders the process.
I've definitely met my share of lazy developers and I have to imagine that the percent of developers that are "undisciplined and impatient" have increased over the years due to an increase in the number of developers needed by industry.
However, it seems that the complexity of most applications is increasing considerably and the rate that technology changes is certainly not slowing down. If I was in a position to hire, I would probably not want to hire specialists (a person with deep understanding of one technology which is probably obsolete). However, I also wouldn't want to hire somebody that can't go deep when needed (I'm glad I'm not responsible for hiring ).
I have pretty much abandoned technical books over the years in favor of Google and Reflector. I still read software engineering books (process kinds of things) and business-of-software books, but I haven't had much success with technical books (with some notable exceptions). The last few I've read I could have easily written (ok, maybe not written, but I didn't learn anything new 
). Other books just rehash documentation that can be easily found online.
Of course that being said, I purchased Petzold's book and will probably read it once I start looking at WPF again (that project got canceled). However, I might also purchase Nathan's book to get a quick overview. There doesn't seem to be any point in knowing why something works the way it does if you have no idea how to use it. WPF seems significantly different than anything I have experience with, so a technical book that tells me of the things I should know is probably better than trying to piece together the technology from 8,480,000 hits on Google .
"I think I am more interested in just encouraging people to look past layout and see excellent prose than I am in disagreeing with Jeff Atwood."
That's fantastic because I agree with Jeff and I think you should too!
Looking past the layout is a little difficult since it's what you see when reading the book -- the interface to get at the content, if you will. Wouldn't it be great if Petzold's books had such good layout that it wasn't necessary to ask people to look past it?
To clarify, I'm not here to argue with you about the value of Petzold's writing (I own several of his books and agree with your observations). I just think Jeff had an excellent point worth discussing regarding appropriate layout for technical books, and it's a bit sad that most respondents chose to completely ignore this point. But... never mind.
"I am helping him as a proofreader (without compensation -- there is no conflict of interest here)."
I would give eyeteeth to be able to do that.
yeap very few developers will take the time to read and understand the deeper implications of the code they write high above. I read from somewhere a long time back that the average developer reads _less_than_ONE_book_per_year_ can you imagine that??
Then guess how many .NET developers will ever gain the interest to read "CLR via C#". Each page of it startles me and makes me worried about the state of the majority of .NET developers. I think it speaks volumes when a colleague (granted, he ain't a pure developer himself) asked me, "Are you sure these kind of books are useful?"
I'm not an end-justifies-the-means person, and after thinking 5 minutes that's my answer as to why developers are the way they are. And I don't think it's their fault - I like affordable footwear as much as the next guy, and there's an entire ecology between the workers and the consumers.
But I've been around long enough to experience the lack of a free lunch a couple times, so it's more than just a saying to me. The universe is wired for balance and we're missing something - and thereby tipping the scales in one direction.
I want a software industry to exist in the US when my younger kids get older, and I'm worried about that. And it's not about money - I'm worried about the tens of thousands of kids pumping out of universities overseas. Kids that actually have to study in school and are taught actual and for-real science *sans* poli-sci-group-think. Kids that experience about 50% more classroom hours *before* college than our kids.
Honest to goodness, sometimes I don't know whether to teach my kids basic electronics and binary logic or how to say "Would you like fries with that?" in Hindi.
"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.
. . . 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. "
1 - LOL
2a - . . . because of a systematic rejection of reflection and understanding by the development systems they live in. "Development system" - the collection of people, processes & tools we use to make software. Mostly what management chooses it to be.
2b - . . . because of a systematic rejection of elegant understanding, anticipation and precision in the job they do, in preference to drama, reaction and instand gratification. Because of a systematic displacement of down-stream consequences away from the people making current decisions.
The human social, business and industry systems developers inhabit encourage and perhaps require "leap and leave development" for one to be professionally successfu. Start actually rewarding people who make software for their contribution to the life-time value of that software as a re-taskable asset and this might change. Not until then.
We have met the enemy and he is us. We are getting not only what we deserve, but what we insist upon.
3 - It took me way less than 5 minutes to answer this, because I've spent way more than 5 minutes thinking about it. If we're a profession shouldn't we think about such things as part of simply being a profession?
I picked Petzold's book in order to gain "deep understanding" as that is always my mission when learning a new technology. But although there are a few good nuggets in his book, there really aren't that many. And the writing style left me wanting to just put it away instead of wanting to continue reading.
A book can be full of "deep understanding". But you can only gain that understanding if you are actually able to read the book.
I usually agree with you Eric but this is not so much about the technical content as much as it is about the writing style. Petzold's other books were never like this. This one was very poorly written and is a really "yawner" even for those of us who seek deep understanding.
Commenting by HaloScan
