I believe this is the type of book that I'd like to skim to see what it has to offer rather than just blindly buy it. This is how interpret some of those points:
* As simple as possible, but no simpler -> Don't get into fancy stuff like e.g: design patterns just because you learnt or know them? Same for other techniques depending your language and facilities? Don't use things just for using them.
* Let your code tell its own story -> Use verbs for functions and methods, nouns for variables and classes so code is understood with minimum effort as is being read?
* Generalization takes three examples -> Sure, first you write a solution, then copy paste it if needed elsewhere as you didn't expect to be reused, third time make an abstraction (function(s), method(s), etc) as it popped up once again?
* A good name is the best documentation -> Picking reasonably good names for all kind of identifiers will make code self-document and understand?
* Sometimes you just need to hammer the nails -> Sometimes you need to be pragmatic and get a thing done, maybe not in the best possible way?
* Code that isn't running doesn't work -> Remove all commented/dead code from a codebase as not only running but might also generate confusion to other people?
I do not want to diminish the content of the book in any way nor sound arrogant, but in the past I've seen similar titles and they weren't offering that much to what I already knew at the time.
Testing is running though but that's not the same as eliminating dead code. If you're writing a library/API, you might not personally use the code or hit the edge cases but other users will. If they aren't tested they don't work is my experience.
* As simple as possible, but no simpler -> Don't get into fancy stuff like e.g: design patterns just because you learnt or know them? Same for other techniques depending your language and facilities? Don't use things just for using them.
* Let your code tell its own story -> Use verbs for functions and methods, nouns for variables and classes so code is understood with minimum effort as is being read?
* Generalization takes three examples -> Sure, first you write a solution, then copy paste it if needed elsewhere as you didn't expect to be reused, third time make an abstraction (function(s), method(s), etc) as it popped up once again?
* A good name is the best documentation -> Picking reasonably good names for all kind of identifiers will make code self-document and understand?
* Sometimes you just need to hammer the nails -> Sometimes you need to be pragmatic and get a thing done, maybe not in the best possible way?
* Code that isn't running doesn't work -> Remove all commented/dead code from a codebase as not only running but might also generate confusion to other people?
I do not want to diminish the content of the book in any way nor sound arrogant, but in the past I've seen similar titles and they weren't offering that much to what I already knew at the time.