Buy this book now!  Don't buy it because it's well-written and full of great advice.  Don't buy it because it's Dave Thomas' greatest creation since the Spicy Chicken Sandwich.  No, buy this book because you'll be paying a paltry $30 US for at least *two months* worth of blog content you can repurpose!   That's *50 cents US* per blog post! Heck, write your own book, swipe most of its topics, and make even *more* money!  You've seen how lucrative the book industry is!!  Have you wanted to look like an expert in your field after a paltry 1/6th of a year?  Then this book is for you!

I wasn't half this enthused when I first read The Pragmatic Programmer.  The book itself is a quick read with approximately 70 tips for becoming or continuing to be a successful software developer.  However, if you've read technical blogs for at least 3 months or taken a look at similar books in the field, you'll quickly realize you've read it *all* before.    How many posts have *you* read about "No Broken Windows"?  "Refactor Early, Refactor Often"?  Heck, "Care About Your Craft"?  Pretty much every blog posts something along these lines at least once in their lifetimes, and *this* blog will be no exception, except when I do you will *know* I'm liberally lifting from them and simply putting it in a sexier, sleeker, metrosexualler package! 

See, originally I thought that the Pragmatic Programmer was a waste of my money.  "Why does everyone love this book when all it does is regurgitate a bunch of blog posts I've read over the last couple of years?"  And then I found out why...because it was written in 2000!!  The Pragmatic Programmer is not the regurgitator, my friends...no, the Pragmatic Progammer is the regurgitee.  Blogs have been getting inspiration or outright *stealing* from this book for more than half a decade!  Why should *you* be left out? 

Regardless, the book is enthralling and you could pretty much read it in a day or even a couple of hours, if you are so inspired to do so.  My only complaint with the book: there's no easy reference to scan all 70 of the tips at a glance. the pull-out reference guide for the 70 tips is *buried* in the back cover of the book!!  Who's going to read through *indicia* and advertisements to get to that??  Who even *opens* back covers of books anyway, except for the admirable Avonelle Lovhauq?  Thumbs *down* for that!!

I'll warn you though, although you'll likely appreciate the advice (even if you do have a feeling of deja vu when reading), you'll likely get just as angry as I did when I read Martin Fowler's "Refactoring".  If this advice is pretty much common-sense *and* it's been around for 7 years, why the hell is the field of software development still in such a sad state on average 7 years later??   I've seen companies that were lucky if just *one* of the 70 different tips were things that their team took to heart.  

In the end, this book gets a 4/5 - for sure, I'd sleep with it at a moment's notice but reading the Pragmatic Progammer is more like sleeping with an aged, seasoned prostitute; you might've seen all the tricks before but likely they originated here.  Besides, you'll just take what you learn there, claim it as your own and then be hailed as the greatest lover in the world*! 

* Yours truly has never slept with a prostitute or *been* a prostitute, despite the fact women offer to pay him for sex ALL THE TIME**
** of course, yours truly is also happily married so put those $1000 bills away, ladies***

Now that I've gotten that negative review out of my system, it gives me great pleasure to tell you that "Working Effectively With Legacy Code" is to "Applying UML and Patterns" as a massive multiple orgasm is to a swift kick in the genitals.  Sincerely, it's that good.

Common responses I've gotten when I mentioned this book to people:

"You really need to read this book!  It is excellent."
"I really need to read this book! I hear it is excellent."
"I really need to read this book so I can write blog posts claiming all of the ideas inside as my own!"
"Reading Working Effectively with Legacy Code gets me so hot...if only you weren't married" (most members of the opposite sex)
"Reading Working Effectively With Legacy Code gets me so hot...if only you weren't married" (Donald Belcham in quite the awkward moment)

Now, if you're like me, you want to cut through all the hype and get to what really gives the book credibility: the author's physical appearance.  In this arena, Michael Feathers gets a thumbs up for being a total bad-ass - look at this photo and render!


Arms crossed in the "G's up" pose, L.A. Raiders style jacket, and that pouty scowl all tell us that Michael is ready for either a fight or a freestyle rap at a moment's notice.  It looks like the development community has found the Eminem to James Kovacs' Vanilla Ice!

If for some strange reason you care more about the actual content inside the book, you won't be disappointed either.  "Working Effectively With Legacy Code" reads like a spiritual sequel to "Refactoring", following up on Martin Fowler's guide with more examples and advice on how to get a crazy, mangled code base under some semblance of test.  There's an even larger emphasis on testable code than in Fowler's book, but I suppose that's to be expected from the guy who wrote CppUnit.  Speaking of which, don't let some of the C++ examples scare you off; there are also examples in Java and even one or two in Ruby!  The concepts in this book are useful no matter what the language, although I do think people inheriting a C++ code base might find this book even more beneficial.  I know that I felt a lot more confident about my ability to tame wild code after reading it, and I'm pretty positive you will as well, no matter what code base you're working off; well, maybe not assembly but you get my drift. 

This book is infinitely valuable for *anybody* who works with code they've inherited from others dead and gone, but it's just as useful for anyone doing "greenfield" development.  After all, most of the code you write is eventually going to become someone else's legacy code - this book will help you see ways to ensure your code is testable in the first place and a great way to expand on what you've learned from Fowler's Refactoring.   That being said, I would probably read Refactoring prior to reading this book simply to get more familiar with some of the refactorings that Feathers discusses, and *why* Feathers has such an emphasis on testable code.

As you might imagine, this book has my highest recommendation (5 stars).  This means I would have ridiculously illegal sex with "Working Effectively With Legacy Code" at any opportunity.  Heck, given the content of this book it would likely even help improve my technique*!

 

"It may help to drink some beer before trying to understand this."

"Your boss asks, 'What have you been doing all day?'  You reply, 'Logging in!' Is your boss happy?"

-from Applying UML and Patterns, by Craig Larman

I feel no shame (nor insecurity in my heterosexuality) whatsoever when I tell you that I'm enough of a fan of the Daily Grind to have a Mike Gunderloy poster in the bedroom at our home.  I can't explain how I got it without violating the terms of the restraining order so let's just leave it at that.  You can no doubt imagine my reaction when I found out that the author of the Daily Grind, a blog I've been reading almost since its inception, actually linked to a post I had written.  Sure, he used the word "infecting" in the description, but when you deal with a cold, analytical mind like Mike Gunderloy's, you take whatever scant bits you can get.  

One notable aspect about Mike Gunderloy is that he has aboslutely nothing to do with Applying UML and Patterns.  However, there are two reasons for my seeming sidebar into nowhere:

a) With his link comes some renewed pressure and accountability.  The vengeful James Kovacs pointed out that my book list reviews haven't been publicly updated in some time.   This needs fixing, so today I have posted yet another book review.
b) Talking about Mike Gunderloy is *still* more exciting than talking about Applying UML and Patterns.

Many of you have noticed that a vast majority of my book reviews tend to lean on the enthusiastic side.  This review is not one of them, despite the interesting single curl drop-down hairstyle Craig Larman displays on the back cover.  Remember this footnote from my review of Refactoring?

"There was actually *another* reason I was near death, but you'll have to tune in next week to find out the answer".

Most people originally assumed I was just courageously recovering from a head cold, but the truth was far more sinister - reading this book nearly *cost me my life*.  Nothing makes you crave death more than slogging through about a 1/3rd of Applying UML and Design Patterns.

Beginning of the book with the best pitch for agile methodologies and an explanation of what the RUP really means?  Fantastic.

Latter half of the book with a description of various patterns and how they fit into UML design?  *Amazing*.

Inception?  SNORE.  And as someone who has read through the entirety of the GOF Design Patterns book, I *know* boring.  

Now, dissing the GOF Design Patterns book is hardly that unique - in fact, it seems like these days it is in vogue to rag on the classic blue book.  However, most developers who have read "Applying UML and Patterns" seem to want nothing more than to spoon with Craig Larman and whisper sweet nothings in his ear for writing it.  As I'm not one of those people (and not just because I'm rampagingly hetero), I can see that my opinion on this book won't be terribly popular with the masses - I can recommend it, but make sure you're not expecting an exciting read.  Thankfully, the latter half of the book or so almost makes up for the plodding nature of the text preceding it.  Larman uses two main examples throughout his book: point of sale and Monopoly.  I was a little disappointed that most of the emphasis went to the point of sale, but part of this is probably my own bias towards Monopoly.  To those of you that find point of sale examples to be incredibly sexually arousing, I'm sure you'll get quite a charge out of Larman's book and I also recommend you see a doctor.

I can't give this thing ***** in good conscience, and yet I can't give it 0/5 either; it does have some useful information and I do feel as if I'm a better developer for reading it.   The first part gets a 3.5 out of 5, the "abyss" pages get 0 out of 5 for nearly ending my existence, and the last half or so of the book gets 4 out of 5.  For those of you who are familiar with my ratings scale, this is like knowing a woman who was average/cute in junior high, gained a whole bunch of weight in high school, and then started working out and became a 20 year old hard-bodied, large-breasted stripper - sure, you'd kill to make out with her now, but would you really have gone through the dark years to get there?  Recommendation to read, but skip Inception if you'd like to keep your sanity! 

This blog was relatively quiet over the last two weeks; it was not because I was fending off advances from Kathy Sierra, despite what you might expect after my previous post.  No, it was because yours truly had a brush with *death* that nearly took him out for good.  That's right, I had a horrendous cold; runny noses, sneezing, congestion -  it's a wonder I'm even here today, courageously telling my story of recovery.  I'm not afraid of death (after all, long-time readers know the kind of excitement that will ensue when that happens), but if I were to shuffle off this mortal coil, who would finish the 27 books in 27 weeks?  Who would become 375,000 pounds of ripped muscle by July 25th, 2007?  Who would be there to be that motivating force for Scott Reynolds?  More importantly, who would continue the long string of Donald Belcham jokes that have put igloocoder.com on the map?  Thus, I struggled valiantly to recover but all seemed for naught...until I chugged 1 or 2 L of extra strength Neo Citran and opened up Martin Fowler's Refactoring. 

"Refactoring" is not a book you read expecting to be angered, and its not a book you read expecting to have the room spinning around while your bed flies through the air.  However, that's exactly what happened to me as I opened its pages and read the story of a scrappy young Martin Fowler and one of his many contracts.  It turns out that Martin was on a project that required about 6 months worth of refactoring.   Martin then brought this information to his superiors.  Sadly, not even his terrifically groomed facial hair could convince his bosses that this was a priority.  Martin's advice was ignored with a "There's no time, we're committed to schedule".  One year later, the company in question ended up having to do a complete rewrite of the now unmaintainable software while Martin faced down a giant metal monster with a furnace for a mouth that was threatening all of New York City, or something like that; I don't really remember the minor details.  C'mon, I was gravely ill!  I'm just lucky to be *alive*!! 

The rest of the book catalogs different code "smells" that creep up on a project (pretty much anti-design patterns) and then the various refactorings that can fix them.  There's also a discussion of when to use refactoring and when *not* to use refactoring (yes, there are times).  These come complete with other examples of engagements that Fowler had, including the time Martin solved the mystery of the Flying Dutchman and the Revolt on Dimentia 5.  While I know this outs my inner geek, I have to say that even without some of these anecdotes, I still consider Refactoring to be riveting reading. 

As I alluded to earlier, reading Refactoring made me angry.  I'm not angry because I can't grow a 1970s style beard like Martin Fowler can; after some therapy I can safely say I've dealt with my lack of facial hair and put it past me.  No, I became angry because some of what Fowler writes, to me, is *common sense*.  Naming methods appropriately?  Embracing code reuse?  Come *on*!  But I'm not angry at Martin - how can anyone be mad at this cherubic face? 

No, Refactoring made me angry at our industry and its immaturity.  The fact that so many projects produce code that *requires* so much refactoring boggles my mind.  Have you ever met a developer who has managed to avoid working on at least one project that was coded incredibly poorly?  I haven't.   Why is this? 

But forget about all that.  You didn't read this review because you cared about Refactoring, or because you cared about making your project better.  You read this review because you cared if I felt better.  I can report that I do - and it's all thanks to this book.  Before I started reading Refactoring, I was coughing, in fits of agony, and laying on my bed waiting to die.  Two days after finishing Refactoring, my head was cleared up.  My cold symptoms had vanished.  In their place was a renewed sense of purpose.  I felt faster...stronger...more ALIVE.  What else could have caused this other than my reading Refactoring?  Was my recovery from this cold merely coincidental?  I don't think so.  Yes, my friends, reading Refactoring saved my life.  It can save your life too, and possibily the life of your project. 

You might have noticed that this review is not dripping with the same sexual tension that...well, pretty much *all* of my previous book reviews have had.  This doesn't mean the book isn't worth your money; every software developer worth employment should read at least the first chapter.  It does mean that Martin Fowler's resemblance to a 1970s porn star interferes with any level of arousal I would have if I were not *firmly* heterosexual (and I am).  My final rating therefore breaks down like this:

Refactoring catalog - *****
Anger-provoking development tales - *****
Story about Martins battle with Dr. Noah Boddy - **********
Martin's lack of hair and giant beard - MINUS **

Total score - 4.5.  This has hopefully taught everyone a couple of valuable lessons:

• Cold medication can make any book better
• If you have facial hair you will *NEVER* be perfect.  Sorry Martin - once you shave I will change my rating to 4.8 stars.  Besides, no one likes kissing guys with facial hair, except for Donald Belcham!   Trust me, Martin - quit hiding behind that mass of facial fuzz and let the world see as you truly are.  If you follow my advice you will never have to worry about "getting some" again!**

(This is #2 of #27 in 27 weeks, referenced in my "How I am becoming a better developer" post.)

I have a massive schoolboy crush on Kathy Sierra.

There, I said it!  Whew!  It's like a massive weight has lifted off of me already.

Don't think I'm the only one who feels this way.  Steven Rockarts and Donald Belcham also think that Kathy Sierra == hottie.  The last time the 3 of us agreed on anything, the EDMUG executive became the most powerful force in the universe, so I'm pretty sure we're onto something here.  Donald has been pretty brazen with his affection (going so far as to pretty much ask her *on a date* at the tail end of a recent post...what a smooth operator) and Steven didn't mention it for fear of "falling down another flight of stairs".  I had my own reasons for keeping this secret.  Believe it or not, those reasons have *nothing* to do with my wife, the sexiest person alive and apparently the only reason some of you read this blog, according to recent comments.  She and I have agreed that Kathy Sierra can be part of my "Freebie 5", so Mrs L. and I are cool.  No, I have kept silent because this blog adheres to the highest standards of journalism.

Even a year ago, I knew that one day I would have to review Head First Design Patterns; but how could I review a book produced by someone on my freebie 5 and still maintain the complete impartiality you're used to?  So I did the only thing that I could do.  It was hard, but it was the only thing that was *right*:  I gave up on journalistic standards.

Now that I've made the ultimate sacrifice, I am telling you that Head First Design Patterns is *almost* as sexy as Kathy Sierra and is well worth your time and money.  Many of you are familiar with the thematic predecessor to this book, which goes under two titles:
"Design Patterns"
also known as
"The Most Boring Book Ever Written"

No one wants to say it, but I will - the original GOF book (though informative) is a guaranteed snooze.  In fact, the only way I ever made it through this book was by reading it on the crosstrainer at the gym so that I could not pass out.    Prior to the release of Head First Design Patterns, this was sadly the only book I could really recommend to developers for learning common design patterns.  Who wants to read a book written so academically as to almost purposefully alienate readers?  Where are the jokes?  Where is the *fun*?  Frankly, where is the *sex*?  I mean, let's take a look at the cover for Design Patterns:


Wow.  A Möbius strip, a blue stripe, and what looks like a random smear of gray paint.  I think we can all agree that the above cover was designed by someone who has never gotten laid.  

On the other hand, let's look at Head First Design Patterns:



This is pretty much the stylistic opposite of the original Design Patterns in every way possible.  It's also far more readable; this is the second funniest development book I have ever read, right behind "The Dating Experiences of Donald Belcham".   It manages to be hilarious, memorable, and informative all at once.  How many development books feature crossword puzzles and "head-to-head" interviews with the Decorator and the Proxy nearly coming to blows?  Heck, how many development books even feature pictures??  Almost none.

As I enjoy witty books, consider design patterns to be an *essential* part of a developer's skill set, and consider Kathy Sierra to be a total fox, you'd assume that this book would get the easiest guaranteed action since Tom Opgenorth's presentation at Calgary Code Camp.  However, two things:

a) the Proxy pattern chapter goes a little too heavy into Java RMI.  Now, I don't care about the entire book being written in Java, given the book's examples are clear enough to pretty much be language-agnostic.  However, 2/3rd of the proxy chapter is spent talking about Java RMI rather than a more abstract example (such as I've seen JP Boodhoo show off from time to time). I would have preferred more emphasis on the abstract examples.

b) Kathy Sierra didn't actually write this book - she was "executive producer" (read: editor?) on this book and the credit for the wonderful writing actually goes to Eric Freeman and Elizabeth Freeman.  It's not fair of me to knock off stars for this given that the Freeman's writing is fantastic, but I need to note it nonetheless as having a crush on a couple rather than a single person made me a little dirty.

This makes the book's overall rating on my ratings scale oddly appropriate: 4 1/3 stars out of 5, much like being in a super-hot make-out session with someone only to have their parents barge in just as things were about to get good...in the end you're a little frustrated but you'd still do it all over again if you had the chance!  The Freemans have crafted an *amazing* book that is the best way to introduce yourself or others to common patterns of design, or to convince people outside of the industry that not all programming books are supremely boring.  Some people might just buy it for the cover like Jonas did - at least, that'd why he *said* he bought it.   Why would you buy a book for its cover if you're only going to tear the cover off and put it under your bed?  I don't get it.

And Kathy - if you ever want a "passionate user" to do some "pair programming", I'm right here baby*!!

* although I am HAPPILY MARRIED - I love you Mrs L**
** and apparently so is Kathy, but I didn't want to mention that and get Donald reaching for the scotch again.  ALCOHOL DOESN'T SOLVE ALL YOUR PROBLEMS BUDDY

(This is #1 of #27 in 27 weeks, referenced in my "How to become a better developer" post last week.)

Rajesh Setty (of the "Life Beyond Code" blog) didn't write "Beyond Code" so that he could seduce men and women alike.  Rajesh Setty didn't write "Beyond Code" so that a legion of ridiculously masculine men would develop ridiculous man-crushes!  Rajesh Setty wrote "Beyond Code" because he cared about software developers and wanted to help them reach their fullest potential - the rest just came as a natural outgrowth of his writing.  

I don't know what to tell you about this book.  I would almost say it was like the "How to Win Friends And Influence People" of the software development industry, but it's so much more than that it's almost insulting to use that comparison.    This book is now *tied* with "Code Complete" as a book that I think every software developer *must* read at least once - *particularly* if you are an independent consultant (and I'm a total Steve McConnell fanboy, so you know this is saying something).  Or alternatively, don't read it at all but at least put a copy of it on your coffee table the next time you're bringing a hot date home - GUARANTEED ACTION.

"Beyond Code", as you'd expect, does not have one iota of code in it.  However, what it does have is a wealth of advice on how to stand out - how to stand out to your client, how to stand out among our peers, how to stand out *period*.  While the book is focused towards independents the advice is applicable to *anyone* who is doing software development for a living and wants to transcend just being just another code monkey into something more significant.  The foreword by Tom Peters says "Read it as if your life depended on it.  It DOES!"  This isn't hyperbole.  It's not a long book at all, but it has a great idea pretty much every second page.  I've seriously not had a ROI per page this high in quite a long time of reading.  

This being said, there are some reasons you might not want to read Beyond Code:

1. you don't want to threaten your marriage or relationship by introducing Rajesh Setty and his prose into it  
2. you don't like getting aroused as you're reading software dev books, unless you're reading Code Complete
3. you feel stressed out when you are chased by hordes of the opposite sex wanting to offer themselves to you in the worst way
4. same as point #3, but substitute "clients" or "employers" for "the opposite sex"

Last week, we had a lively discussion on career security on this blog; if you read this book, take its advice to heart and truly implement it's advice, I am almost 100% certain career security is never going to be one of your problems.   Nor will getting some, for that matter!

If you are at all familiar with my scale for rating books (see the bottom of this post for an explanation), then you know that the rating for this book is academic.  No matter how depraved, no matter how undignified, there is *NOTHING* I wouldn't do with this book!  All the way for CERTAIN, even if the only thing I've have the next morning is a goodbye note on the pillow along with some scars and memories to haunt my sleepless nights!  And trust me, sleepless nights are all you're going to get after reading this! 


BUY IT AS SOON AS POSSIBLE.  Then, once you've done that, *read it* as soon as possible!

No, Donald, I'm not referring to the code you write! I am referring to one of the many things I learned from reading the pulse pounding *THRILL RIDE* of the century, "You: The Owner's Manual" by Michael F. Roizen and Melmut Oz, which is part of the series of books that includes "You: On a Diet" and "You: Ultimate Cage Fighter".    As entertaining as mocking Vista can be, I thought I'd take a small break from it to share this *vital* book review with you...before it's too late.

We start our tale of intrigue and biological espionage with a small quiz: to give *you* the chance to prove that you are a master of the human body.  Unfortunately, while I am a master of everything else in North America, my score of a *whopping* 17 out of 50 on their multiple-choice exam indicates I obviously have a long way to go.  This despite my scoring a 19.1 on their related RealAge test a year or so ago!!  I smell conspiracy.

Regardless, I'm not bitter about this in the slightest; for in the end, I learned a *TON* about the human body, including:

• The reason why men can drink more alcohol than women, unless that man's name is Anand Narayan
• The reason why size *does* matter!! 
• Why Q-Tips are not for ears
• How to find out whether you have enough stamina to have sex (however, this does not teach a developer how to *get* sex, which is likely a topic needing an entirely separate book)
• the one similarity between the brain and the penis
• and *especially* for Donald, why it's okay to have regular doses of alcohol, and which ones are most beneficial (sorry, buddy, scotch is not mentioned)
• a cartoon diagram of the rectum!
• and *MORE*

I don't want to spoil all of the shock twists and surprises that this book has in store for you, but let's just say that the B and T cells have a tough fight ahead of them. 

The good:

• So much information.  I learned something new on every page, and I can assure you that this has nothing to do with my gross incompetence!
• PLAIN ENGLISH.  No obfuscation going on here, my friends.  Everything is laid out in almost 3rd grade style.  Lots of pictures so that you're not intimidated by all those confusing words!  It's almost like "Head First Human Body"!

The bad:

• the jokes, much like the pick-up lines of many developers I know, are beaten down and seen better days.

The ugly:

• No matter how cartoony you make a diagram of the human rectum, it is still a diagram of the human rectum.  That being said, I know of one bonafide rectum fan who will pick up this book for that alone!

Final word:
The book is a 5/5 - I'm ignoring all the negatives here because at worst this book will teach you something and at best it will save your life.   If only Captain America had read this book - things might have been different.  From previous reviews, you know that I would *normally* engage in wall to wall whips 'n chains with this book.  But not this time - after all, who is really into getting hot and steamy with someone obsessing over how much gas the human body produces every day?  *TOTAL* turnoff, gentlemen!  But a strong, *healthy* recommendation otherwise.

I own a lot of books.  Actually, I probably own *too many* books.  So many sit unopened, saved for a later date because I only have so many eyes, brain cells, and waking hours.  It is for this reason that my review of Bob Reselman's Coding Slave takes place quite a while after the book's release in 2004.

Given that my review isn't terribly timely, you might have read other reviews and concluded that the central message of Coding Slave is that our system of software development is horribly broken, leading to unmaintainable systems managed by undertrained, overworked developers.  Or that the solution is to form some of engineering style guild run by developers for developers, where this mystical union takes care of both training and pay, ya da ya da ya da.  *Who cares*?  You know what Bob Reselman has taught *me* through this book?  The average user persona is way too boring.

When I'm writing user personas, I don't want to write about John Xavier, the middle-aged man who is looking to track his fleet of vehicles.  I want to talk about "Albert Schulberg, aka BigDick6969" (actual character in Coding Slave) and how "his priorites are to achieve orgasm and achieve inebriation, preferably in that order" (actual *quote* from Coding Slave).  Or Ajita Ortihawamein, the sassy and scrappy young developer who will lay down with anyone and anything to ensure the client is pleased!  Where are *these* kind of people in our documentation?  I'm not telling Steve McConnell how to write, but if the next edition of "Rapid Development" had people like these in its case studies it would be a GOLD MINE.


But you're not here to listen to me rant about user stories; you want to know whether this book is worth your time and money.  Let me put it this way: if you read McConnell's "Professional Software Development" but thought, "Man, I wish this had more menage a trois scenes to engage me as a reader", then Coding Slave is *definitely* the book for you.  Of course, if you are reading Steve McConnell's books in the hopes of seeing some sex scenes, I would suggest you have greater problems to take care of before you start worrying about the state of the software development industry.

I know what you're thinking, "Coding...sex...violence...Justice gives this a 10 out of 5".  Wrong.  Yes, I definitely think that it takes some testicular fortitude to even imply that we might as well be doling out sex along with code in the future, since we're either whoring out our brains or our bodies in the end.  Please understand that there is no bias involved in the non-perfect score for this review; I've read books by hippies before, and I'm totally cool with it.  


The reason this book isn't getting umpteen out of 5 is that it takes half of the book for things to even get started.  I understand that Bob does a bit of setup here, but I felt that the sidebars on the Frank and Walt characters were unnecessary for his main points near the end.  I freely admit I could be missing something here.  I have tacked on a bonus point here for the name of the "one ERP to rule them all" on page 138.

Coding Slave is really 4 parts: 1 part violence, 1 part code stories, 1 part sex, and 1 part essay.
The depictions of violence?  Awesome, vivid, but only very brief moments in the book.  We needed a bar brawl or something!  3 stars.  
The stories re: the coding, the monolith systems, the poorly documented code?  We've all been there.  4 stars.  
The sex?  Uhm...well, I have to admit, you can tell these sex scenes were written by a software developer.  And no lines like "Let me insert my element into your array, bow wow chika wow wow?*"  2 stars.  
The essay?  Best part of the book, and this is definitely a slightly less academic way of putting things than McConnell does (I would note that there *are* differences between the two but I'll go into them in a later post, possibly).  Thanks for including "The Meno" in the appendix.  5 stars.  

Using the incredibly complicated math of adding this up and averaging the scores out, we come to a rating of 3.5 out of 5.  Those of you familiar with my previously established ratings scale know that this means it comes somewhere inbetween a peck on the lips and a full-on tongue thrashing with this book.  

Let's say that "Coding Slave" is a bit of an awkward kisser but shows potential for improvement; thus this book is still worth your time if you have a little bit of patience to get to the good stuff!!!  Recommended.

At work recently, we’ve been having a small contest.   Each of our developers is allowed to select 5 technical books; we then merge all of the selections into one large list, and each developer votes for 8 books to purchase for the library.  Every developer can also add a brief description to his selections.  Here are 4 of my selections. 

Peer Reviews In Software
Are you Cuban and harboring an intense attraction to the rampaging mass of manly masculinity coding that text messaging application, but he just doesn't seem to notice you?  Looking for a good way that you can somehow get the two of you alone to make your big move?  Maybe you should try a "code review"!  Code reviews, in addition to spiking up the average developer's productivity, are a great social mixer and a way into someone's heart!  Who *hasn't* gotten hot and bothered when you recommend that they should perhaps refactor their class structure to incorporate the strategy design pattern?  Read this book and you'll no longer have to sing "I will always love you" at the top of your lungs…after a couple of code reviews, they'll be singing to you!   Karl E. Weigers has done it all - requirements books, code reviews, even your momma!!  Now let him do what we does best and guide you through topics like:

• Overcoming resistance to reviews
• Inspection teams and roles
• Inspection process stages
• Scheduling inspection events
• Analyzing inspection data
• Peer review training
• Critical success factors and pitfalls
• Relating peer reviews to process improvement models

The Art of Computer Programming, Parts 1-3
The feel-good book of 2005!  It will make you laugh, it will make you cry…it will make you *remember* what it was like to truly live.  Donald Knuth, the Santa Claus of Computer Science, dispenses his legendary wisdom on a variety of topics.  Knuth's multivolume work, widely recognized as the definitive description of classical computer science, is now available in an attractive, boxed set. The three volumes included in this set have each been revised recently to reflect developments in the field.  If you don't want this book with unrepentant lust, then you have no soul.

Bundle of Algorithms in C++, Parts 1-5

You wanted the best?   You've *GOT* the best!  Robert Sedgwick desparately wants your love - and you'll be made for loving him after you read *this* book!    Sedgewick has completely revamped all five sections, illuminating today's best algorithms for an exceptionally wide range of tasks.  If you're looking to experience a book that will change your life, the lives of your parents, and the lives of your children, YOU SHOULD VOTE FOR THIS BOOK.  After reading this, nothing will ever….*ever*…be the same!!   Robert Sedgewick is so hot right now.

Becoming A Technical Leader
Admit it - you want to be a technical lead.  You want to inspire people to new heights.  You want to one day crush people's hopes and dreams in your icy grip.  You want to lead the communist revolution against our proletariat masters!!  Or maybe you just want the groupies that come with being a technical lead.  You know what I'm talkin' bout!!  So let the pimp daddy himself, Gerald Weinberg, tell you were it's at!  Reviews on Amazon include the statements "if you ever want to be a technical lead, then read this book, or you are doomed.  Doomed to BURN.", “I have never gotten so much action”, and "Why does my used copy have the pages all stuck together?"

Now tell me – even if you aren’t a developer – aren’t *you* motivated to vote for these selections?