Aaron N. Tubbs bio photo

Aaron N. Tubbs

Dragon chaser.

Twitter Facebook Google+ LinkedIn Github

If you are writing a technical book for a technical user, don’t write introductions to each chapter.

“Insightful Quote” – Obscure Quoted Person

“In this chapter we’re going to explore the yada yada yada…” (10 sentences)

“The first section of this chapter, Goobers and Gooseberries, explores yada yada yada…”

“The final part of this chapter, …”

“Pithy Quote” – Less Obscure Quoted Person

This is, with few exceptions, one of the biggest wastes of paper and reader time ever to grace a technical book.

If there is a need to write an introduction, it better have some value in and of itself. You know why the O’Reilly books are good? For the most part, they’re not full of bullshit — they’re full of content! Open up the beginning of any arbitrary chapter in Programming Perl, and you’ll notice that what first looks like introductory boilerplate is diving deep into something useful that teaches one something, , rather than just providing summary metadata for the content that follows. If I wanted the author to repeat some material, I would re-read that material.

What I’m getting at here is that I’m about to throw The Pragmatic Programmer out the window. There is some good content in this book. A lot of it, as the author indicates, is common sense, and is going to be apparent to the seasoned software engineer. For people just getting out of college, having never had a full-time development position, there’s a ton of good content. For somebody who has been in the industry for a while, there still meaningful sections.

However, the pages are full of worthless metadata and fluff. The book is full of constant cross-referencing (especially at the end of every section of every chapter, where half a dozen other sections are mentioned). Worse are the crimes against usable visual space, including (but not limited to) meaningless graphics design elements (huge headers, section indicators, massive fonts, overzealous line spacing, huge insets, unnecessary padding graphics on tips, … the list goes on. Best case, perhaps 50% of an arbitrary page is actually used for content display, and of that 50%, maybe 50% is left after all of the junk is stripped out. What it looks and reads like is a paper somebody wrote in high school where they failed to meet the minimum length requirement, and had to resort to graphic tricks, metadata, and typographical hacks in order to meet the requirements.

This brings us to the second problem. Hunt and Thomas seem to enjoy blabbering on about things, convinced that the reader is an idiot and needs to be held by the hand and bludgeoned to death with every concept they cover. All of the good content in the book could be reduced to a long pamphlet. Hunt and Thomas seem like experienced software engineers, but they are horrid at writing concise advice for software engineers. Unless you’re a fan of the self-help genre, I think most software engineers would find this book offensive in its repetition, verbosity, and clumsy progression.

What this leads me to realize is that all of this metadata and junk is here because nobody in their right mind would actually read this thing like a book cover to cover. They are going to pick it up, select a section at random, skim it a bit, maybe look at some related stuff, and then never open the book again. With luck, they will find a sucker to pass it to with the advice that there is “good information inside, you should read it!” I’m convinced nobody in their right mind would read this book cover to cover, and I carry with me the opinion that a good book should make you want to read it cover to cover. I’m going to try and force myself to finish it, but so far this book is very unimpressive. Preliminary rating: 2/10.

Please, if any of you have read this book and have a positive take on it, let me know what I’m missing.