Rating: 
Summary: Brilliant. An Absolute Necessity for every programmer.
Review: Having been through a half dozen companies as a programmer, engineer, architect and grunt, This is a book that would have saved me months of hassle, weeks of headaches and a lifetime of frustration.
Learn how to deal with marketing and management, and to do it in a way that won't get you fired.
This will teach you processes, (I know, that word is such an anathema to some) and techniques, as well as how to introduce them to your current work environment. Read this. Apply this. It will get better.
The next time you're thinking of buying a book for work, be it 'Effective Java', 'Perfect Perl' or 'Suzy's C-Shell's' - Don't. Buy this one instead.
Rating:
Summary: A great read and very insightful
Review: Having only worked in small companies, I found myself nodding a lot to what Chris has written and it's not just limited to Corporate America!
Even down here in Australia, we experience the same strange behaviours from those who are supposed to "know" yet don't.
Chris's book has great advice for anyone who develops software for a living and anyone thinking about developing software for a living.
A book every software developer should read and have on their shelf.
Rating: 
Summary: Full of cliches and stereotypes with little content
Review: I bought this book as a result of a favorable review on Slashdot.
I should have known better. Perhaps if you are right out of
college this book might have a few good tips, but those are buried
in cliched prose and observations of the obvious. Here is just
one example: "One of the all-time classics, the crusty and cranky coder is a
timeless symbol found in trade magazine advertisements
everywhere. Far from fiction, these are very real people.
With a diminished patience for others sculpted from many
years of corporate ineptitude, these folks tend to be
irritable, frustrated, and they just basically want to be
left alone. Or else. They may or may not appear to have
any teeth, but it's wise not to antagonize them. This
is particularly good advice for the young. They may seem
powerless to affect your life, but tick them off and you're
liable to find out exactly how they've managed to survive
in the business world for so long." Along with the "crusty coder" we find "suits" (those would
be managers and marketing types) and, of course, our heroic
software engineers, who are just artists that want to be left
alone to develop beautiful, high quality software. Instead
they find themselves bogged down in deathmarch schedules on
software projects with constantly expanding feature lists. While there is some truth in this picture of the life of the
software engineer, it is so obscured by cliche and stereotypes
that it is of little value. An underlying theme of the book
is that programmers are oblivious "propeller heads". With
their heads in the clouds of object hierarchy, programmers
rely on the author to point out that those who pay for
software development expect a return on their investment. The author never mentions a core fact in the life of most
software engineers: they don't do development. Although most
of the literature concentrates on designing and implementing
new software, in most cases programmers fix bugs in and extend
existing code. The really ugly truth is that many programmers
spend most of their time fixing huge masses of undocumented,
poorly designed code that was written by engineers who have
long since departed the company. The book seems to be heavily slanted toward large
corporate IT software development. It is copyrighted in 2002.
It does not mention that the programmers in large corporate IT departments, where you might really find examples of the
empty "suits" described in this book, are disappearing,
as programming jobs are exported to India, Russian and China. When it comes to Silicon Valley, the book is much less accurate.
The management of companies like H-P may be populated
by professional managers, but it is increasingly rare to find
managers who do not understand the technology or the
software development process. Even IBM is producing
interesting and innovative software these days. Good managers
are like good anything else: they are rare. But the portrait
of idiot managers in this book is right out of a Dilbert
cartoon. Yeah, they exist, but in the current savage technology
environment they are an endangered species.
The founders of start-up companies don't have a simplistic
30,000 foot view of technology. They know the technology,
even if they are not implementing it. In most cases the
they are very bright people. This book has a section on the importance of quality assurance
(QA) departments and the author denounces software that is
shipped without testing (who can argue with that). But what
he totally misses is that even when they exist, QA departments
are ineffective. QA should be part of the development process,
not some separate department populated by lower status engineers.
The QA people should work closely with the developers, not
as some separate department, sending the message that quality
and testing is not something that developers worry about. The author is, apparently, a software consultant. He writes
that there are always jobs around. I suspect that as he was
writing the book, the world was changing around him. For most
people, software consulting has dried up. In fact, in the
current environment, you're lucky to have any job that pays
a decent salary in software development. While in the past
you could leave a situation you did not like, this is no
longer true. Some writers can use a casual writing style to express real
ideas and good observations. This book uses a casual writing
style to express empty ideas and the obvious. Save your money
and buy Steve Maguire's excellent book "Debugging the
Development Process" instead. Maguire's book has real content,
is easy to read and has some solid useful advice.
Rating:
Summary: Witty and Enlightening
Review: I must say I am not impressed with many books, but this one has blown me away! The author's insight into the many facets of the business world gives the programmer who reads this book an edge over those who don't. I'm recommending this book to every programmer I know.
Rating:
Summary: One of a kind. A must have for all developers!
Review: I picked up a copy of this book a week or so ago, and I must say it has been a wonderful read. Chris is dead on with the politics and problems us programmers have to face day in and day out. I read the book constantly shaking my head and saying "Yep he's right". One of my favorite chapters, and a topic I didn't expect to be covered in the book, was chapter 12 "Controlling Your Destiny" was very informative and helpful. If you are reading this review right now then you are already interested in this book. Do you self a favor, pick up a copy, you won't be disappointed. This book is a one of a kind, and Chris's writing style is great. "The Career Programmer:" is a very easy, informative and rewarding read.
Rating: 
Summary: Good For Some, Better For Others
Review: I read this book after reading praise for it on the Internet. Being fairly
new in the world of corporate programming I was eager to read this. While
there was plenty of information in the book, not all of it was relevant to
me. This book provides advice on everything from handling the politics of the
work place to running efficient meetings. Even the short time that I have
been in the business it was amazing how accurate the author's descriptions
were. I took away a wealth of information on how I should view the
requirement, design, and implementation phase of a project. I say that the book may be better for others because it seems to be geared
more towards someone who has just become a project manager or a lead. The
advice on how to handle managers and meetings is not something I plan on
encountering right now as a rookie; however, it is good knowledge to keep in
the back of my mind. So in conclusion, my only reason for giving the book 4 stars and not 5 is
that some of the information did not pertain to me at my current career
stage. Otherwise, I highly recommend this book for programmers at all
levels.
Rating:
Summary: The Message Is Obvious
Review: I was very unimpressed with this effort. This book was a bitter book that was not well written nor well edited. I'm still grasping for the point, and what use it would be for most. I want things I can use - that's why I buy these things. I just didn't find it useful. A poor effort from what I'm finding to be a poor company (this is my third - and last - purchase from this publisher, and I haven't enjoyed any of these books. I sense a trend)
Rating: 
Summary: Bitter perspective uninspiring
Review: I was very unimpressed with this effort. This book was a bitter book that was not well written nor well edited. I'm still grasping for the point, and what use it would be for most. I want things I can use - that's why I buy these things. I just didn't find it useful. A poor effort from what I'm finding to be a poor company (this is my third - and last - purchase from this publisher, and I haven't enjoyed any of these books. I sense a trend)
Rating: 
Summary: Gird yourself for a depressing look at your career!
Review: If you are a programmer who is constantly persuing self-improvement of your software development skills, but is frustrated by your social development environment (i.e. Management), this book is for you. You care enough about yourself to try and fix your troubled environment. After you finish this book, I suggest giving Pete McBreen's Software Craftsmanship a read, and follow that with Alistair Cockburn's Agile Software Development. Duncan's book shows software development as a battleground of politics and ego-tanks-Duncan suggests ways to survive that crazy mess. If you actually want to change the way you develop software, McBreen and Cockburn show you the door. I finally finished the Career Programmer after putting it down so many months ago because...I found it...depressing. Why? I lived that crazy mess. However, I have a hard time pinning down who his intended audience is--the Sr. Programmer, the middling programmer, the junior programmer? He certainly addresses all of these, sometimes from paragraph to paragraph. I suppose that he's writing to them all, or more appropriately-to the program manager that's been promoted from Sr. Engineer. I guess this because he talks about accurately tracking your activities (a PSP tactic), Managing your Team, and Putting together your Testing Team. This is obviously a mix of topics that's going to apply to a project manager. Duncan repeatedly puts the onus on the reader to be responsible for these activities because no one else, and certainly not your management will do these things for you. (Depressing.) He compliments this advice with more survivalist wisdom on politics: don't stick your head too high and get fired. Don't lay too low and ignore the politics game and get fired for becoming redundant. Make sure to kiss up and make sure to praise management but suggest ideas on how their protect could be "better" with ideas from the other corner of your mouth at the same time. This endless list of survival tactics is guidebook material for beginning programmers, but like I said, if he's writing to project managers, it behoves the project manager (or Sr. Programmer) to teach their Jr. programmers these tactics. It would be a very intimidating book to read for the entry level programmer. However, entry level programmers, in my experience, don't read much (they Know How To Program: bring it on!) and it's the team lead programmers who by discovering failure, start reading these books. Thus, this book is yet another depressing account of Thinks You Should Have Known. Duncan, in his wisdom, points out something that many a programmer has oft reflected on: career path. He doesn't talk about this to much point, but his section on it says: have a thought about what kind of developer you want to be before you jump into the industry and let it mold you into something you regret. How many of us feel molded even now? Too many. I reflect on how a doctor or a lawyer could easily make the same kind of mistake--let their industry whisk them along and wake up to find themselves as a profession in a field they failed to choose. However, this book is saturated with irony: almost all pointed advice Duncan gives is to subvert the system. Sneak in your testing staff. Sneak in your design time. Lie about what you're doing to give your self time to do things management is too ignorant to approve of. Duncan writes: life is too short to work for clowns, but if you have to pull these stunts to build a development team, to what degree of clown do you stop working for? People concerned about the reality of the software industry should pay attention to the reality presented in Duncan's book. I think that many of the topics that Duncan raises in his book are artifacts of Scientific Management and Software Engineering. The environments that Duncan describes - offices full of idiotic ego-battles where people talk about producing software - would not exist were Pete McBreen's vision of software development the existing reality (a reality where people cared about getting the work done as it reflects their reputation). I also find it interesting to note that much of what Duncan writes has been written by Steve McConnell in Rapid Development and Software Project Survival Guide. However, McConnell and Duncan describe something much closer to the Software Engineering environment than what, in my experience, is actually the reallity for smaller application development projects. I had echoed the ideas McConnell promoted for lack of any better writing on software development. However, after reading McBreen and Cockburn's respective works, my views on how to develop applications have radically changed towards the Craftsman approach. McConnell, in After the Goldrush provides many good arguments for the Licensing of Software Engineers, McBreen compliments McConnell's tack that such licensing efforts-are only rarely applicable.
Rating:
Summary: So much wasted paper...
Review: One of the other reviews marks this books as "Great no nonsense look at the reality of corporate life" -- and is laughably wrong. It's not a great book due to the overwhelming presence on nonsense that makes me hypothesize that the author was paid by the page. The entire first paragraph on page 131 (opening "Fighting for Quality Assurance") is nonsense about how quality assurance is like socks that go missing in the laundry. My other leading complaint about this book is that it's about 10 years too late for most "Western" programmers whose only advantage on their Asian replacements is their proximity to the business customers -- that is, the advice to "Get your requirements etched in stone" is most useful when you're 10-12 time zones from your customer and most politically dangerous when you're a mere 10-12 feet. This might have been an insightful book to read back in college prior to any disillusioning professional experience. But modern corporate software development needs competitive advantage rather than strict adherence to existing practice if it's going to survive in high-cost locations like the USA -- and this book offers no insightful competitive advantages. It just offers spare socks and the watchman's over-anthropomorphized dog.
| 
