Code n00b: Throwing the Book at ‘Em
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?
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.”
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:
- People who are deeply knowledgeable coders
- People who have excellent teaching skills
- People who have solid technical and explanatory writing skills
- 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.