Hyrum’s Law If you are maintaining a project that is used by other engineers, the most important lesson about “it works” versus “it is maintainable” is what we’ve come to call Hyrum’s Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (Location 260)
Consistency has great value, but generality comes with its own costs, and you can often win by doing your own thing — if you do it carefully. (Location 603)
the ever-widening gap between CPU cycles versus memory latency impacts what “efficient” code looks like. (Location 332)
“Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase.” (Location 355)
We’ve also learned that having a dedicated group of experts execute the change scales better than asking for more maintenance effort from every user: experts spend some time learning the whole problem in depth and then apply that expertise to every subproblem. Forcing users to respond to churn means that every affected team does a worse job ramping up, solves their immediate problem, and then throws away that now-useless knowledge. Expertise scales better. (Location 390)
One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs. (Location 463)