Julio

Great book and definitely one I'd recommend, but not all chapters equally.

It starts off strong. It defines complexity for the purposes of the book and why it's problematic, and then goes on for a few chapters on how to avoid it. Separates strategic “focus on the design” coding and tactical “get it working” coding, and spends the whole book emphasizing that you want to be strategic most of the time.

The next ~8 or so chapters go about what is good design that reduces complexity. I recommend chapters 4 (modules should be deep), 6 (general-purpose modules are deeper), 7 (different layer, different abstraction), 8 (pull complexity downwards), and 10 (define errors out of existence). They have solid and concrete advice that I haven't seen elsewhere, at least not explained so clearly.

Chapters 12 and onward have some interesting stuff but I think it declines compared to the first half. Skim through them and see if anything catches your eye. Two interesting ideas I noted down are:
* From Chapter 19 (Software Trends), that in agile development we should consider the iterative unit of development the abstraction and not the feature. That is a way to combine the quick iterative approach of agile with the strategic programming approach encouraged by the book.
* From Chapter 20 (Designing for Performance), a way to approach improving performance while keeping the code clean - by focusing on what the “ideal state” would be of the critical path in terms of performance and then approach it following the rest of the advice of the book.

Overall a book I liked a lot and would probably recommend the first half of it to pretty much anyone.