BOOK REVIEW: 97 Things Every Programmer Should Know - Part I

I'm reading the book and would like to share my opinion about it.

Technicals
Version read: February 2010: First Edition.
Free review links:

• Google books (90% content)
• Amazon (Table of content + content)

My first impression reading the book

   My first impression was very good, the book started with ideas I've learned to understand by bad experience and good books advices.

Highlights

• Don't take your time, no matter how easy it looks.
• When given a project/job/work-item, don't 'take your time', be fast - especially at the beginning of the project and don't tempt to do shortcuts to save time it'll cost you with great interest ('lava flow' anti-pattern) later on. 
• If you have debt's - manage them (excel / notepad ... any way) and repay them as soon as possible.
• Apply functional programming principles.
• Less mutable depandancy will make your functions more durable to variables state (especially in multi-threaded domains (see immutable definition).
• Ask yourself 'what will the user do', talk to him, interview him, show him basic GUI behavior, include him, watch him in action.
• Most of the user behave in the same basic way to complete a given task.
• They also make the same mistakes.
• Prefer obvious way of doing things than faster (shortcut) ways.
• What the user request and what he really wants usually have a big gap.
• Watching a user for an hour might save you a lot of redesign later on.
• Watch the user work is better than guessing what he needs.
• Automate your team's codding.
• Use auto generated code tools.
• Creates code templates for reuse.
• Use formatting tools.
• Use static code analyzers to find anti-patterns and break them if found.
• TDD your code, measure test coverage.
• Apply written guidance for important things you can't automate.
• Guidances should be dynamic according to the project evolution.
• Do the above for the important things.
• KISS principle!! 
• Simplicity
• Readability
• Maintainability
• Speed of development
• 'Sounds good' / beautiful design/solution/code.
• Read others code
• Find a good open source expert code and read it, refactor 'Microsoft.Net' code for example.
• Simple objects with single responsibility.

Next: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_08.html