Throwing the Book at ‘Em – InApps 2022

Fairly often I am asked to recommend resources for learning computer programming and web development. There are multiple online resources I wholeheartedly endorse — Gordon Zhu’s Watch and Code for JavaScript, Smashing Magazine for more advanced front-end web dev tutorials, Free Code Camp for people just getting started — but I admit to being pretty stumped when beginners ask me for book recommendations. As in, you know, printed words on paper pages.

It’s not because I’m surprised people want to learn analog-style from print media — I, myself, often prefer the same. I take notes by hand instead of typing them, for example, because it helps me learn better, and overall I feel like I retain information more easily if read from a page instead of a screen. My paper copies of Kyle Simpson’s “You Don’t Know JS” series are dog-eared and heavily underlined and bristling with post-it notes. Yes, the whole enchilada is available for free download from GitHub, but I shelled out serious (for me, anyway, back when I was a barely-self-employed n00b developer) dollars for the print version. See previous re: dog-ears, underlining and post-it notes.

There is actually some recent science to back this up, that analog materials are still the most effective way for most people to learn anything. Studies these days seem to indicate that most people take in, and retain, information more effectively from note-taking by hand and overall learn better from books than screens. Yes, lots of people learn lots of different ways, and there is plenty of room for debate here but let’s go with the hypothesis for now. Because my query is not whether books are better for learning how to program. It is why are so many books written to teach computer programming so terrible?

By which I mean, why are they so badly written, in terms of stringing words together in a row to convey a concept or, you know, even make simple freaking sense?

Because most of them are. Of course, some are better than others, and some — a very few — are truly excellent. I myself am fond of Jon Duckett’s visual learner-oriented guides to HTML/CSS and beginning JavaScript, which I often recommend to students. And then there are the widely proclaimed classics, like “The Art of  Computer Programming,” by Donald Knuth. I think of these classics of computer programming in the same category as great classics of literature like “Moby Dick”: everyone says how incredible they are, but I’ve yet to meet anyone who had read either all the way through.

Unfortunately, most computer language programming books appear to do just the opposite, giving confusing or simply useless explanations of concepts, then providing code samples that are overly simplistic or just plain stupid.

Overall, though, most programming books suck — and my standards for technical books are not exactly sky-high. The language doesn’t have to be fancy, I don’t need humorous illustrations or stunning metaphors to keep my attention. Just give me simple words that add up into a decent explanation of concept, throw in useful code examples, and I am a happy girl.

Unfortunately, most computer language programming books appear to do just the opposite, giving confusing or simply useless explanations of concepts, then providing code samples that are overly simplistic or just plain stupid — i.e. nothing you would ever see or do in actual programming — and, too often, wrong to boot. You drop yet another one to the floor beside your desk in disgust and think, who writes this shit?

But write it they do, and by the metric ton. So these days I definitely check out Amazon reviews (filtering for those written by people who appear to be actual programmers themselves) before purchasing or even borrowing technical books. And in the process have developed a bit of a sick hobby of enjoying the user reviews on bad books. Like this gleeful reviewer going to town on a particular O’Reilly Java text: “On the back cover it even promises that ‘You’ll master the art of writing error-prone (sic!) code!’ — this reference to ‘error-prone code’ sadly confirmed as soon as one starts reading.”

Oh oh oh and then there’s the guy who writes about one of the most widely revered learn-you-some-beginning JS tomes out there, “This book is written in a convoluted, meandering style, where the authors goes on about how NOT to do things, instead of how TO do things. This type of nuanced approach is great for experts, but it’s hell for a beginner. Also, I suppose the attempts at humor are commendable, as the author is trying to spice up some dry topic areas, but it’s unnecessary. More energy should have been spent in learning how to teach better, and less on trying to entertain.” I actually had exactly these thoughts myself when, early in my own JS learning curve, I read this same oft-recommended book. Which I shall not name except to say the title rhymes with Eloquent JavaScript. Oops.

But I digress. Why are learn-to-code books bad? My guess is, mainly because there is an enormous and seemingly endless market for technical publications and instruction these days. Any time there’s a market, people will, of course, rush to fill it — generally as quickly and cheaply as possible. Cheap and quick are of course the nemeses of quality; now combine this with fact that it’s just about impossible to find genuinely qualified people to write these books. Let’s try a little exercise: Draw a Venn diagram. Label it “People Who Should Write Programming Books.” Include the following sets:

1. People who are deeply knowledgeable coders
2. People who have excellent teaching skills
3. People who have solid technical and explanatory writing skills
4. People who for some reason are not choosing to make a shit ton of money using skills 1 through 3 to do other things.

Now, see what you find in the intersection of those sets. Wait, what intersect — ooohhhh.  Riiight.

Not that there are any forces driving publishers to do better. People will still buy terrible programming books. Because, really, what else is there for us to buy?

I leave you with one more Amazon review, possibly my favorite ever:

“The author is probably a productive software architect. Some points are interesting, though nothing could be defined as advanced. He does not know Java better than any average developer, and this book does not add very much to an intermediate level, apart, maybe, from a warning about writing books: Writing a book can transform you from a good developer into a bad author.”

Feature image from Pixabay.