I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

On historical overviews in programming books

Two new reviews of the book appeared early this week. Roger Johansson reviewed it on his own site, and Mike West did so on Digital Web Magazine.

Thanks, both of you, for taking the time to read and write about my book, and for being so very positive about it. In the remainder of this entry I'd like to say a few words about an interesting difference of opinion that surfaces in them: the value of historical overviews in programming books.

Two schools of thought

Roger and Mike have vastly different opinions on this. Roger says:

I particularly enjoyed the first two chapters, in which ppk describes JavaScript’s purpose and context. I felt a bit like I was reading a novel instead of a book on programming, maybe because I’ve been working with the Web long enough to recognise myself in ppk’s historical overview of JavaScript.

I'm very, very happy with these remarks; in fact, I worked long and hard to obtain exactly this effect in the first two chapters. I seem to have succeeded as far as Roger is concerned; and that's good to hear.

Mike, on the other hand, thinks that the historical overview in 1C is unnecessary:

However, I think Koch falls into the typical programming-book trap of explaining a bit too much historical background before moving into the real meat of the topic. I understand why it can be a valuable exercise, but I think parts of the book’s introductory chapters are bogged down with information that simply isn’t relevant enough to the process of creating working web pages today.

Obviously I agree with Roger. If I'd thought the historical overview was unnecessary, I'd have left it out. That's not to say that Mike is "wrong"—you can't be "wrong" when you give your opinion on something as elusive and non-exact as history—it just means that I think I know better <g>.

"Say No to history"

That's not the end of the story, though. Nick Finck followed up with a pointer to Better Beginnings: how to start a presentation, book, article... by Kathy Sierra, which is, as far as I'm concerned, far too negative on historical overviews. Under heading "3", she writes:

For the love of god, DO NOT start with history!

If I read just ONE more book about the web that starts with a history of the internet, I will have to take hostages. Seriously. Do any of us really need to know about DARPA and CERN and...? Do most web designers and programmers really care? No, and No. [...] WHY DO AUTHORS KEEP PUTTING THE HISTORICAL OVERVIEW AT THE BEGINNING OF THE BOOK?? If you feel driven or morally obligated to include the history of whatever, fine, but don't put it at the front. Stick it in an appendix or on a web page, where it'll do the least damage.

Oh dear, she seems to have been exposed to too many historical overviews. Or rather, too many bad historical overviews. Being both a professional historian and a professional web developer, I feel honour-bound to refute her thesis.

Why do authors keep putting the historical overview at the beginning of the book? Because history, by definition, happened before the present. Therefore a historical treatment should come before the treatment of current affairs and practices. Simple.

Historical overviews to establish credentials

The key to the real problem lies in "feel[ing] morally obligated to include the history of whatever". Here I think Sierra is on to something. Many people feel that a history of whatever topic they're treating is mandatory, even when it sheds no light on "the process of [using the described topic] today", in Mike's words.

I think that many (most?) historical treatments fall into this category. The writer feels he has to treat history in order to establish his credentials, but doesn't really have anything useful to say except for "technique X was invented by Y in year Z".

This problem is not restricted to programming books alone. There are far too many historical introductions, and even whole books, that are devoted to breathlessly proclaiming the totally obvious.

Author [writes]:
The original United States were once British colonies! (No, really, they were!) That's why we still speak English! (Incredible, isn't it, how these historical thingies all fit together?!)

Author [thinks]:
Wow, these stunning revelations sure established my credentials!

These bad historical overviews (written mostly by amateur historians) should be wiped out. On that I agree with Mike and Kathy. However, when they call for a total extermination of all things historical they ignore the purpose of history.

The purpose of my historical overview

History serves to explain stuff. Why are there two event models? Why is there a de facto Netscape 3 standard? Without a historical overview you'll never understand. That's why I included it.

Can you do without the history? Sure you can, if you're just interested in inserting effect X into your pages. As soon as you want to get JavaScript's big picture, though, a historical overview is mandatory. Besides, as far as I know my thesis of alternating thin and fat phases is new, and I want to show it off.

Therefore I take the liberty of changing Kathy Sierra's thesis slightly:

If you feel driven or morally obligated to include the history of whatever, fine, but make sure you're saying something useful.

In order to form their own opinions on the purpose of JavaScript, my readers need to know about the thin and fat schools of thought and their influence on how JavaScript is perceived and written.

Therefore the historical overview, which discusses these constantly shifting definitions of JavaScript's purpose, is a nutritious part (as Zeldman would say) of chapter 1, which is appropriately titled "Purpose".

Wendy Sharp, my editor, agreed with me. In a few of the early drafts of the technical chapters I included historical overviews of event handling and such (at the beginning of the chapter, of course, since that's the only proper place for historical overviews).

Wendy was adamant: these overviews had to go because they didn't add anything to the chapters they were part of. After re-reading them in the context of the entire chapter I agreed and deleted them.

Later on I delivered chapter 1. Although Wendy sent me her usual wealth of editorial notes, hints, and changes, she never once questioned the basic necessity of the historical part. In fact, she requested another short historical overview in 1B in order to explain why there are two layers of JavaScript standardization. After all, history serves to explain why stuff is as it is, and at this point in the book such an explanation was necessary.

Besides, I hope to give a view on JavaScript's past that's different from the usual run-of-the-mill JavaScript histories. (I'm a professional historian, after all, with professional pride to match). Fortunately the very first comment on Mike's review shows I succeeded:

actually thought the historical intro material was one of the best parts of the book. [...] there was something about the way he framed it that made it all click in a different way for me.

This is exactly what I intended, and I'm very happy that my idea works for at least one reader.

In short, a bit of history is necessary for true understanding of the big picture. I therefore disagree with Mike West and Kathy Sierra when it comes to the usefulness of historical overviews. Although I admit it probably won't work for all of my readers, I hope a significant majority will feel it's a worthwhile addition to the book. Do you?

(Update 26/dec/06: Wendy Sharp reacted by writing an entry on this problem. She turns out not to agree with me entirely, and the differences are interesting.)

Comments

Comments are closed.