Summary
Thoughts on writing software how-to books, and why the examples invariably stink.
If you own any computer-related book subtitled with "in 21 Days or Less", this article is for you.
Around 1995, I decided that I would do whatever it took to learn Java, except take a class like any reasonably intelligent person would.
The decision to learn Java was a reflection of past experiences with the likes of Germ Foster and Crumb Jones, who spoiled my interest in learning Perl and C/C++. Since the Internet was going to be this big thing, and as I felt I had mastered HTML and JavaScript, I chose Java as my next language.
Today, lining my bookshelf, I have a nice collection of nonsensical how-to books on Java.
Each bares official sounding names that scream JAVA as though their treasure of knowledge was the one true resource and no other publication was worth reading.
The industry heavyweights threw their somewhat respectable subsidiary names behind the publications.
With names like "Slumlord Press" and "Tony's Garage-based Startup Emporium", it's hard not to feel the awesome power radiate from the front covers.
And if you've ever purchased up one of these exquisite volumes, you would know why I never learned Java by reading them.
Most how-to books related to beginner programming provide a brief history on the language, major modifications made over the years, and then dive in with a good, solid hello world sample.
Since Java was a relatively new language - more mainstream in 1995, mind you - the purpose of having a background chapter on the history of the language seemed rather moot.
Yet, there it was.
And in thirty or forty pages, I discovered that it was made, updated fifty thousand times, was based in part on C/C++, and wasn't used anywhere, though it should have been.
It wasn't that I happened upon one lousy author, or even one lousy press.
An entire segment of the programmer/writer industry was devoted to churning out fast food books on how you could learn a complex language in a short amount of time.
It was, and still is, as ridiculous as any book that purports to assist you in mastering something in a short period of time that rightfully should take at least ten thousand years.
Nevertheless, I was determined, and I powered into the first book.
It began with a complex introduction on object orientated programming, onto a Hello World sample, and went straight down hill from there.
In case you are wondering, the sample resembled something like the following:
public class HelloWorld{
public static void main(String args[]){
System.out.println("Hello World!");
}
}
Consider the logic, compared to a spoken language being taught to a child.
Do you start with a broad history of the language and its advanced syntax, or with the ABCs and how each letter can be used to make a word?
This was not a book for experienced programmers, so what was needed were the ABCs.
Eventually, I would discover Ivor Horton's and O'Reilly's books, and my struggle would be over.
Until then, I had to first find out what I should have been looking for in a programming book.
After the first three chapters, I knew that first book was a lost cause.
It was speaking fancy to me and I was confused.
The next book - again in the same thread of a "in 21 days" book; apparently I'm a slow learner - began a bit better.
They all start with a Hello World application, but this one provided a better explanation of the whole "class" business.
Unfortunately, it immediately went into some hokey example that didn't compile, and it stuck with that example through the entire book.
Eventually, I found an errata page containing all of the author's errors, but by then I had given up.
By this time, I was frustrated.
I had spent more than 21 days making Hello World programs in Java, but still did not understand why it did what it did.
What, exactly, was a "public class", and why did I have to type "System.out" everytime I wanted to print something?
It would be some time before I picked up my diminished interest in learning Java.
Until I did, however, there had been a slew of other books like the Java-related ones, which all espoused that I could learn some complex language in a short amount of time.
Only, this time, I just read them in the bookstore, and then put them back on the shelf where they belonged.
Now, I like to read them like most people read cheap fiction.
They are so out-there that they are brain candy: no nutritional value, but fun to read.
I'm truly amazed at how some of these companies select authors, much less stay in business.
I can imagine how these purported authors get their work published.
It reminds me of an acquaintance, Ivanhoe Puck.
Ivanhoe was an exceptionally intelligent individual: in his field.
He was very well-learned, and very respectable: in his field.
His field was not in computer science or software engineering.
It was in the liberal arts arena.
Therefore, he surrounded himself with bitwise parasites who throve on the attention that only a liberal arts major can supply.
In exchange, he was able to infect them with his own software engineering visions.
That's fine, though.
If a bitwise parasite wants attention from real people, that's their problem.
What bothers me is the combination manages to convince people that Ivanhoe is an authority on the given (however unnamed) subject.
Ivanhoe wrote - with a great amount of help - a megalithic, and, arguably, completely useless piece of software.
But, because he had an armada of socially-inept bit-munchers, he managed to convince all with whom he came into contact that he, and only he, was a brilliant engineer.
If you ever met Ivanhoe Puck, you would probably never be able to see the conspiracy: he has elevated himself in the world of programming on the shoulders of the aforementioned bit-munchers.
Call me unfair, call me jaded, call me bitter.
But if Ivanhoe Puck ever writes a book, it would be in the same vein as a "in 21 days or less" book.
And that is where these programming publishing houses acquire their authors.
Not the people who are in the know and can teach (such as Ivor Horton), or those who know so much they are at the point of being confusing (Stroustrup and O'Reilly's), but people like Ivanhoe.
The coversation probably went something like:
Ivanhoe: "My book covers the many facets of this subject, of which I am the undisputed authority; I have many other programmers who will back me up. I feel it would be a good fit in your line of books because my book compliments the other books and picks up where they left off."
Publisher: "You're hired."
Don't believe me? Pick any publisher who's name is a three letter acronym or where the book title is in the same vein as a "in 21 days or less" book.
Gather up all of the books from those publishers for a specific language.
They all start with the same thoughtless examples, fail to teach the language, and contain so many programming errors that it is impossible to make it past the fourth or fifth chapter.
Plus, the actual content is so idiotic that you became confused.
Not the good kind of confusion that comes from a really good book, but the bad kind that leads to such exclamations as "Did anything in the last ten pages make a modicum of sense?"
There are several good books, some mentioned above, that do a very good job.
And, there are a lot of books that could be used to start your BBQ if you ever run out of lighter fluid.
But the lesson was learned.
Don't trust any programming book unless it can fully teach me the complex behavior of Hello World in 21 days or less.