As most other reviewers, I was drawn in by the glowing commentaries here on Amazon.
As background, I've been programming professionally for nine years now, on a variety of projects, but generally high-performance embedded stuff. I'm interested in improving my software development & management skills, and have read a number of other, better books (listed later) about these topics.
My first criticism is that the collection of 50-odd tips are simply too shallowly presented to be very interesting. Generally, if you agree, you say, "yeah, duh," and if you don't, there's no discussion of the point, and no attempt to address known difficulties with "good" practices. There also seemed to be no attempt to balance some of the points. For example, the authors repeatedly talk about writing your code so it's flexible. In general, a good idea. On the other hand, they really seem to think you should be writing everything, regardless of what sort of application it is, to run on different machines, under different operating systems, with and without concurrency, etc. This, to me, just seems foolish, extra work, extra code, extra bugs. The estimates I've seen (in other, better, books) say that just writing re-usable code takes three times more work than "normal" code, ignoring multi-platform complexities.
The old school comment (and I consider myself fairly old school) is there because they very obviously come from a Unix/command line environment. I will admit, they motivated me to improve my scripting skills, something I've been planning on doing for a while. But then they have inane advice, like "use only one editor *for everything*". This is perhaps nice, if you can, but on larger projects or organizations, this probably isn't possible. I use the IDE required by the project, a different editor for documentation (also required) and a third one for doing hex & advanced search and replace. Perhaps with emacs and 47 scripts this wouldn't be necessary, but I'm not convinced it would be efficient either.
All in all, the advice is generally good, but I think there are better books out there (e.g. Code Complete, Writing Solid Code, Rapid Development, The Mythical Man-Month, C++ Coding Standards). As a light book to get you thinking about your craft, it's not bad, but that's the best I can say about it.
