Herding Cats: A Primer for Programmers Who Lead Programmers

Good

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.

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...).