Disclaimer: I do have a small credit in this book. A long time ago, the author mentioned that he was looking for people to help out, so I stepped up. It was only participating in discussions like "What do you think about version control's use in industry?"; I didn't help with any actual writing, and yesterday was my first time reading virtually all the final content. No monetary interest, of course.
I've been doing a lot of reading over the last few weeks, some of it technical, some of it non. I've been meaning to type up a few book reviews, and yesterday I finished reading my copy of Josh Carter's "New Programmer's Survival Manual," published by PragProg. Since that's a bit lighter material than Spinoza, I figured I'd write it up first.
The Survival Manual is intended to be the book you should buy after you graduate from college, but before you get a job. It's a bunch of tips, arranged by topic, that give you a taste of what 'real world' programming is like, as well as what working life is about. I think that it accomplishes this goal wonderfully, but if you'd like to hear specifics, read on.
One of my roommates is not particularly technical. She picked the book up, and read the introduction and the first tip. She then said something that, after reading all of it, I agree with 100%. "I like this guy's writing style. It's very... readable." Josh's prose feels... comfortable. Like you're talking to a down-to-earth friend, or co-worker. Which is great, given the topic. I really enjoyed the actual reading of this book. Especially in technical books, this is a great quality to have, but I guess this book isn't exactly technical; it's much more about soft skills than hard.
I also really enjoyed the cookbook-style organization. Basically, the book is one big ball of tips that you can read individually. They're grouped together with three or four others that are on the same topic, but each stands alone, and they cross-reference each other when appropriate. While I sat down and read it front to back, I'd imagine it's pretty easy to cherry-pick certain things and read it in a more non-linear fashion.
I also feel that 'pragmatic' is a good description of most of the content. In particular, as much as we all love DVCS, the book frankly states that most places still use centralized version control, which is totally true. He makes sure to carefully not be particularly dogmatic about the specifics of anything, focusing on strategy more than tactics. For example, "Get good with your editor, make sure it can work effectively without using the mouse, for speed," not "zomg emacs r teh suck, use vim."
Finally, Josh links to copious other works, and provides references for all of it. Some stuff is just general internet culture, but the bibliography alone would assist any programmer in finding some useful primary materials to read. Here's the first six: SICP, Getting Things Done, Extreme Programming Explained, TDD By Example, The Mythical Man-Month, and Foundations of Object Oriented Languages: Types and Semantics. Oh, and just because there's some XP/Agile stuff in those particular books, don't think it's slanted towards that: waterfall is explained as well. Just so happens those books were first.
There's not that much bad that I can say about this book, really. There are a few small things, though:
There's a 'white belt brown belt black belt' metaphor that's supposed to indicate a difficulty of each tip. Given that there's only two black belt tips, I didn't feel that three levels were really needed. I also just thought that there wasn't a huge difference between white and brown, either, so I'm not sure that it really adds any utility.
Because this book is fairly high-level, it might be hard to actually apply
these lessons. This might be more of a problem with readers than with the actual
book, but I can't count how many times I (and others) have said "Of course,
write descriptive variable names!!1" and then typed
x = 5. It's just the way
things are. And since this book is essentially a collection of advice at that
high level, I can see someone reading this book, and then just simply not
following the advice. I'm not sure if this is something Josh could have fixed,
or if it's inherent in this kind of book. Also, it won't affect a diligent
reader. It is something to think about, though.
This book is totally worth it. The style reminds me of the seminal Pragmatic Programmers. If you're a freshly minted graduate, put this book at the top of your reading list, then also grab a copy of all the books in the bibliography to read later.