Pragmatic Programmer : Chapter 5 - Bend, or Break

 This is one of the chapters in the book that causes it to be a bit slower. There’s a lot of concepts and obvious pieces to this chapter for an experienced developer, but they’re good for newer developers and ideas to be reminded of.

28. Decoupling- Anyone who has worked on an older, tightly coupled project knows how difficult refactoring significant components out can be. The best option is to never get to into the trap of having the rigid structure. It takes practice and an occasional glance at your dependency diagrams. The idea of asking versus telling is a concept that I also need to work on myself, I've had a pattern of asking, and I need to get away from that.
    Additionally, wrapping things into an API, like global variables, is something that seems obvious, but I don't see many developers willing to do.
29. Juggling the Real World - We get a set of four strategies that help with event driven development. The book continues to talk about different states and how to handle in those scenarios. I think its a great introduction to the observer pattern and pubsub, but wish there was more detail to it. The problem is that this book doesn't go into super fine details like the implementation of that. It gives you a jumping off point.
30. Transforming Programming - The basic idea is that we often overcomplicate things. We should be trying to reduce how we think of our methods as input and output. The architecture in the way we do it is just another tool in how we can handle the different objects and methods. 
31. Inheritance Tax - Interfaces, Delegation and Mixings/traits are key pieces to avoiding the Inheritance Tax. I believe that the use of polymorphism is important, and so do the authors. Creating a protocol with the interface allows a separation of concern, and allows you to program against the interface.
32. Configuration - The older I get, the more I love configuration. Historically, I used to set a lot of variables in configuration files. I abstracted those into its own class so I could write automated tests against them. Then it hit me, for most of them, I can hit the database on application start to populate them, or potentially refresh the variables without having to do a code deployment. And today, I take advantage of Key Vault -  It allows so much in terms of flexible behavior in your code that you don't realize until you have a mature application.