Even though I read a lot of technical books, either I must have pretty good instincts or the publishing quality bar is quite high, because I never read one I thought was totally worthless. Until now that is.
I’m not even sure where to begin. As soon as I try to put my thoughts together, a whole rush of negative points immediately comes up and prevents me from even organizing them in some sort of coherent way. I suppose I’ll start with the easy part and share the only two useful bits of content that I was able to glean from the book:
- Logic doesn’t prevail in the corporate world.
- Programmers need to understand managers and managers need to understand programmers.
Both of those are very valid points, and understanding them will help anyone developing software for company. There, no need to buy the book anymore. I’ve just saved you $29.99 + tax, a few hours of your life, and medication costs from elevated blood pressure.
OK, now that we’ve gotten that out of the way, why was this book a complete waste of time? The first problem is one of style. The author is probably a very entertaining speaker. He might even be a passable column writer. He has a light-hearted style and is ready to make a joke at moment’s notice. I like jokes as much as the next guy. I also like chocolate fudge, but I would throw up if I were forced to eat several pounds straight for dinner. That’s how this book feels.
The problem with the jokes is more than just a style issue. All the funny remarks and irrelevant (and mostly incomprehensible) jokes about chihuahuas are just a cover-up for the total lack of content. Reading a chapter of the book is like eating cotton candy: You go through the motions, it takes a while, but in the end you haven’t really eaten anything.
Then there’s the attitude. I think that’s probably what most got to me. The author has a “cowboy” attitude that permeates the whole book. You know the type I’m talking about. Coding is the coolest thing in the world, and, left to his own devices, he’d just spend all day and all night in his office hammering away at the keyboard. His ideal vision of programmers is that of “professional athletes and rock stars.” He also naturally assumes that everybody reading the book feels the same way.
His distinct dislike of everything academic is very telling about the general attitude. He couldn’t possibly learn anything of value from those ivory-tower mad scientists. He goes as far as to be totally disrespectful and referring to people as “terminally educated” and implying they’re worthless in the workplace.
With that attitude he forges ahead and starts spewing horrible advice. Not a word on how to improve a project, not a word on how to deliver a better product. It’s all about saving his butt and enjoying his coding. Everything else is secondary. He doesn’t go beyond that and assumes everything will remain the way things are. For example, he takes for granted that you’re going to spend most of your time in the debugger tracking down bugs. Hello, how about minimizing those bugs and taking steps towards catching them in other ways? I wonder if he’s ever heard of unit tests, test-driven programming, or agile methodologies. There’s certainly not a mention of them anywhere. Too busy coding I suppose.
As if things weren’t bad enough, the overall message of the book is to try and put up with evil Corporate America, deal with it and do your coding job, and if things go bad, quit. Nothing wrong with quitting, but that seems to be the motto of the book. Not surprisingly, the author’s biography lists his claim to fame being a consultant for a bunch of companies without any particular accomplishments. Just a string of failed projects after failed projects. No wonder he’s burned out and jaded. Is this the guy we want to be taking advice from?
Finally, the most of the advice he gives is either outdated, ridiculous, or just plain wrong. He pretty much advocates a waterfall approach to development, and “getting your requirements etched in stone”. I really couldn’t believe it when I saw it. I thought it was a joke. Maybe that works for consultants getting paid by the hour trying to make a fat check and do their coding undisturbed, but it doesn’t work for those of us trying to create a good product. Or maybe that’s a technique that works in corporate America? I think not.
The only saving qualities of the book were that it was relatively short (just a bit over 200 pages), so the pain didn’t last for too long, and the fact that I actually had fun writing this review. This was the first book I read by this publisher (a! APress), so I’m going to be very cautious with any of their other books in the future. Stay far away from this book unless you’re masochistic or your idea of an ideal workplace is something like The Office.