Journal Chacham's Journal: Book Review: The Career Programmer: Guerilla Tactics for ... 2
I recently finished reading The Career Programmer: Guerilla Tactics for an Imperfect World by Christopher Duncan after reading about it in a Book Review.
The reviewer gave the book a 9.5 and didn't give a 10 because it demands defined requirements. The reviewer is an idiot. (That sound pretty harsh, so if you read it, i apologize.
The book is interesting for its subject matter. It is a book that covers the programmer in the workplace. There are many ways to do that. According to the Keirseyan model, there are four. Most programmers are NTs, with a nice amount of NFs, a few to none when it comes to SJs, but SPs are a strange lot. There are probably more SPs than SJs in your local programmers pit, yet, specifically the ISTP can be found in greater numbers. Being dominant T, they jump easily into INTP mode, but being an S they are quite realistic. This book was written by an ISTP. And therein lies its greatness, and also its greatest fault.
ISTPs, are SPs. As one book basically puts it, SJs follow rules, NFs bend them, NTs question them, and SP break them. The writer cares not for rules, and only uses them for his advantage. And, he expects others to do the same. This will not bode well for SJs, though given their small numbers this would be of little consequence. Still, the NFs would like to keep them, and the NTJs might be interested in keeping them.
The author further states that he wrote the book like he talks. And he is thankful for that. As an SP, this works well. However, everyone else would do better without it. The book follows what sounds good, rather than logical order. Though, not fully, as it follows logical order too, just not perfectly. Further, almost ever paragraph ends off with some quip. The first time it was funny, but after that it got annoying. And those comments about the watchman's dog made me think less of him each time i read them.
The first fifty pages or so of the book are redundant. It could have easily been written in five. Either way, they can be skipped with no loss to the reader. If someone wants to read this book, they already know what he is going to say.
The middle of the book has good information, and some decent approaches. That is, a quick design method, how to figure out what can be gotten and what one can get away with, how to ask for more than one knows they will give so one can bargain to what has already been decided, how to lie about time spent just to get more time, and so on. Good information, presented pretty well, and probably worth a skim by most programmers.
The end of the book was written hurriedly and the sentences do not flow as well. However, there are more facts. It's as if he got tired and stopped the silly show, and finally put forth straight information. As such, it is a much better read. It also addresses a programmers view of himself, rather than how to cheat others.
This book basically addresses people who work in large companies, and where middle management are SJs (they probably are, but not always). If you're an SP, and working for SJs, this book is for you. Change either of those, and the book simply will not work. It may be an entertaining read, but the practical aplication of the ideas becomes severely depressed.
As a final note, the book is written about company politics. The author describes why they are important, why one should care, and what happens if one doesn't. If you *still* don't care, this book is not for you, as only a few pages will matter. Although, i personally would advocate the knowledge that such politics exists is important. As long as there are two people in the company, there are politics.
The subject matter of the book is thus quite important. I'd give it a 9. The writing style is okey, but leaves much to be desired, and is even somewhat annoying, so i'd give a 6 or 6.5. The layout of the book is poor. All the paragraphs are left-justified, instead of the normal left and right, but the font is good, so it's gets a 4. The flow of the book, which is choppy, but gets better towards the end gets 6 (though Ps probably won't care). The approach to the book is defnitely SP, though with some bending towards other types, as such it also gets a 6. So, perhaps the book as a whole gets a 6.5. If someone else would rewrite this book, it could be a real winner.
All in all, the quality leaves much to be desired, but this book is definitely worth reading.
Addendum: (Forgot to mention this earlier)
As an SP the author advocates doing what he does best, that is, the use of tactics. Programmers are usually NTs (strategic) or NFs (diplomatic), and as such, even though they may be able to use such tactics, it is not their best methodology.
Painful but useful read? (Score:2)
Re:Painful but useful read? (Score:1)
You mean appalling? I'm thinking of appealing an apealling orange....
It sounds like most computer literature. Important but painful to read.
TJs should write technical stuff. Just like only TJs should create database schemas. It's just right up their alley. T means clear distinct definitions (as opposed to the fuzzy F definitions). And the J means a) it is defined in its place (one place as opposed to a little here and a little there) b) the writer say what it