|
|
The author is attempting to offer "a comprehensive guide - think of it as a field manual - to the management challenges of supervising and leading programmers" in the format of a "how-to manual that's both practical and thought-provoking". This is quite an undertaking, and any book which makes the reader sick and tired of the author's style before the end of the second chapter certainly has its work cut out.
I yawned at the frequent asides to hammer home yesteryear southern heritage. I tired of the steady stream of Star Wars/Star Trek/Southern/philosophy footnotes. I sighed at the slow peptalk-paced delivery.
By the end of chapter 3 the book might as well have been subtitled "misery loves company", and then it occured to me. Perhaps the text had been soaked in some stereotyped character of some sci-fi-loving, well-read IT bod. Perhaps this was a calculated move to gain empathy and offer a sense of companionship? Hoping to hook the lost at sea, wherby it works best for the new leader; looking for a mentor, a friend, someone to nod an affirming head.
Regardless if this was the intention, the author had all but alienated this reviewer before 50 pages were through. In that space the author had managed to usefully profile various types of programmers and how to work with them - borrowing from Brooks' "Mythical Man-Month" in the process - getting the reader thinking about staff to understand their positive and negative traits and how they may interact to contribute or detract from productivity and goals. Also of worth was the material in chapter 2 which invites the new leader to reflect and assess themselves.
Sadly, from this point onwards I felt that the paw-tagged summary boxes sufficed to convey the usefull content. While the author asserts that these boxes exist to save the reader on postit or highlighter costs, I believe it is to save readers from losing patience wading through the flowery, heartfelt - yet vague - language, which I found all too often failed to captivate or inspire.
A particular curiosity of this book first crops up in chapter 4, where, following a dismally shallow assessment of existing project administration and planning tools, the author goes to some length to introduce alternative software he chose to write to suit his own requirements in this area. Despite suggesting that you use existing tools if they work for you, the author states; "I've found, however, that many organizations and especially individuals are very particular about how they want to organize their electronic world.". This being the case, it is a waste of paper and a distraction to then give so much detailed coverage (including screen shots) of the author's attempt to address what he personally regards as a shortcoming of exisiting tools.
The author's sofware is indulged yet more coverage in the two appendices. Appendix A, while offering more insights into the features of the software, offers the source code for download.
The expected readership is presumably capable and experienced programmers who are to lead other programmers. Yet, under the guise of instructing the reader in how to conduct a code review, the author's software is given even more coverage in Appendix B. This includes an offer to email him directly should you wish to contribute some opinions or insight on his code.
How many pages in all were given over to what appeared to be ego-stroking or an advertisement? 17 pages, or 6.7% of the book.
I was so concerned at the coverage of the author's software that I examined the Index to see what treatment it had been gifted. Here is an ordered list of all indexed entries which have 8 or more sub-indexed features.
- leadership role - 51
- leadership - 16
- programmers - 15
- programmer - 14 (overlaps with 'programmers')
- author's software - 13
- software development - 12
- technical leadership - 12
- software architecture - 8
- meetings - 8
Staggering.
Back on topic, the author offers up some decent pointers for the new leader to use to underpin their efforts as they move forward in their career, sandwiched between management and programmers. However, most of the supporting text fails to justify its inclusion on the page and a crib sheet is really all the reader will take away from this book.
Summary
Assessment of writing style is subjective. I couldn't stand the author's style and I'm amazed that the publisher allowed the author the self indulgence regarding his (non-existent?) software throughout the text. Did I take anything from the book? Yes, but for what little I found, I would have resented paying for the surrounding text. I can't bring myself to recommend this book.
Table of contents
Ch1 : Adapting to your leadership role Ch2 : Managing the leader Ch3 : Leading the herd Ch4 : Organizing for success Ch5 : Managing meetings Ch6 : Philosophy and practice of technical leadership Ch7 : Leadership in eclipse Ch8 : Leadership redux Ch9 : Working with your boss Ch10 : Words without a song Ap A : Caring for your pet : The administrative director software Ap B : Poking your pet in the eye : Code review of the administrative director Bibliography Index
