Customer Reviews

Herding Cats: A Primer for Programmers Who Lead Programmers

5 star:		(1)
4 star:		(3)
3 star:		(3)
2 star:		(1)
1 star:		(3)

 

 

So I got this book: Herding Cats: A Primer For Programmers Who Lead Programmers, by J. Hank Rainwater. When the programmers I manage came into my office they'd see it and they'd say, "We're cats?!" "Better than being sheep," I answered.

Although I was put off by the author's photos in the introduction, and he quotes Steven Covey, it actually turned out to be quite good: it crystallized my thoughts in some areas and gave me brand new thoughts in others. And when you mostly agree with someone, maybe you should give those items you don't agree with, or rarely think about, another look.

The points I agreed with: avoid unnecessary meetings; leads can't be programmers anymore, but leads have to still code; hiring people you can't communicate with is no good, even if they're superstars; keep track of the tasks people are working on (duh); software development is more like gardening than construction (watching Greenfingers the other night I discovered that gardeners go through a design phase too); micromanagement is bad; geniuses shouldn't be made managers; borrow from software methodologies, don't accept one as a whole package.

And the points I realized where I had room for improvement: delegate, inspect, organize, and manage meetings. Since I read the book, about a year ago, I've tried to follow some of his advice in these areas. Some of it has worked, some hasn't, but I don't regret experimenting with any of it.

If you're like me, and you read almost every software management book you can get your hands on, this should be in your collection too.

Actually, I bought this book as a gift for my boss, but as I'm often called upon to mentor small groups myself (being the dinosaur of our department), I decided to read Rainwater's work over the weekend (being careful not to ear-mark it). As the book's introduction says, the first three chapters themselves are worth the money. Of course, this book isn't really for those lucky enough to have studied management (though even those would profit from the programmer "type" descriptions). But for all the other programmers destined to lead programmers, this is exactly what we need; the chapter about managing oneself is especially insightful. All common sense stuff, really, but sometimes a good spec (and this book can be seen as such) is needed even for things we already know, but don't practice. Rainwater's English is a joy to read, though I guess some of the in-jokes (given only as footnotes, so as not to disturb the flow of the otherwise serious text) are only understandable the "old" school programmers (yes, such as myself...).

I really wanted to like this book. The first half of the book is well-written, and brings up good points. But the second half of the book is very light on substance and uses clichés everywhere one can see. I was also embarassed to read about the cross-national case study, as it hinted at xenophobia.

The one rather good aspect of the book is its bibliography, since it provides narratives along with the books.

Rainwater offers much advice on what are mostly intangible issues of leading a programming team. In large part, he directs this at a senior programmer or developer who has hitherto dealt mostly with purely technical matters. But now you've risen to this supposedly exalted management role, where your background may not be enough for you to feel fully comfortable.

So Rainwater talks about various soft topics like recruiting, conducting meetings and evaluating your team. Reassuringly, he says that with concentration you can develop and improve these skills.

But he also makes an astute observation. That thinking is absolutely crucial to your success. That you should practise this continuously and not just in the office. What he says here is correct, but the scope is not limited to just those leading a team. If you're a technology professional, ultimately your value comes from applying your intellect to the utmost. As a professional inventor, I found his remarks to be spot on to my situation. Where by focusing steadily on a problem, I have found novel solutions, and depths to the problem that in turn led to more complete solutions.

There are a few bright spots, but for the most part this book is just plain common sense. The guy does seem to know what he is talking about, but doesn't do a great job conveying that to the reader. The writing style was just plain annoying and the book constantly went off on tangents (ex: "The philosophy of da Vinci", "Why you should read classical literature", "Anti-patterns").
At one point after reading an entire paragraph explaining why he used the word "forecaster" rather than "prognosticator", I put this book on the shelf in disgust. The author obviously has a thesaurus and a copy of Barons and uses them liberally. The theme of the book seems to be "look how smart I am". What I equally annoying is that this book is written like an informal e-mail at times, for example he inserts "just kidding" and personal annecdotes completely unrelated to the topic throughout the text. Overall there was a heck of a lot of filler in this book.

The good part is that I got lots of good stuff from this book. I started viewing leadership differently and some paragraphs were quite a revelation.

The bad part is that the book is somewhat hard to assimilate. Some issues:
1) From a high-level the book is well structured. But when you dive into the small and little details, the information looks a little disorganised. The contents of some chapters left me with the impression that they are not finished.
2) The author is very good in presenting his own past experience but the book doesn't go too far beyond that. On one side, this strategy is right - you can't go wrong if you speak from experience! On the other side, I see his approach somewhat limiting - a book about management and leadership should go beyond the experience of a certain individual...
3) The style assumes probably too much the "geeky factor".
4) The author lacks completeness in many of the topics. For example, I think a lot more can be said about process management.

Anyway, probably there is a "perfect treaty on management" somewhere. This book is the opposite of that other "perfect" book. You find here fun-to-read sets of advices and stories on management, focused more on the author's personal experience.

Don't confuse this book with the classic, "Managing people is like herding cats" by Warren Bennis.

This book is well-intentioned, but I feel sincere pity for anyone who works at a company where these are the right rules. Here are some random bits of 'wisdom' from the book:

= The deadline is everything; people should be fired for missing deadlines
= If the VP of sales asks for something stupid, your job is to deliver it as quickly as possible
= Software developers can be stereotyped to make it easier to manage them - stereotypes like "slob", "magician", etc.

As other reviewers have noted, there's a constant and useless intrusion of quotes from Star Wars, poetry, and other sources, intended to support the simplistic conclusions of the author. Do not read this book; choose "Peopleware", as others have suggested, or the Bennis book.

Thanks to this marvelous piece of literature, I found myself acquainted with a variety of colorful terms such as "like white on rice" and what it means to "hair-lip hell." Fortunately for the hapless reader, the author has graciously provided footnotes to explain these and many others. Quotation from the Matrix and Star Wars movies are also abound. Unfortunately, all of the above failed to alleviate the trauma that afflicted me as I swung between drowsiness and frustration while I read this book.

Team Leading is both an art and a science. As such, one can't expect to find a how-to book with specific instructions on mastering the subject. One can only hope to find common sense and experience distilled for easy digestion by the newcomer. This book fails to cover either science or art. It reads more like a crippled hybrid between Steve McConnell's "Rapid Development" and Stephens Covey's "Seven Habits", with plenty of clichés sprinkled throughout for good measure. The author's attempt to classify programmers into "types" is laughable and useless, and the constant underlining of the special traits and shortcomings of our geeky friends is resentful.

For the science of software team leadership, I would highly recommend the McConnell set of books. For the artistic and social side of the equation, I would recommend the Seven Habits book. You'll find all the knowledge that you would need in these books. Applying that knowledge is the real challenge. A challenge that can only be overcome with discipline and understanding.

I liked this book. It wasn't an all encompassing book on everything about team management, but it was a good, easy read. I'd recommend it.

Well, I'm always looking for good books on this subject, but sadly I can't recommend this book to anyone.
You would be far better off with "Peopleware", which I would unconditionally recommend.