diff --git a/PRINCIPLES.md b/PRINCIPLES.md
index 51a0191..7429065 100644
--- a/PRINCIPLES.md
+++ b/PRINCIPLES.md
@@ -250,4 +250,6 @@ See also [Calm programming / Slow programming](README.md#calm-programming--slow-
 * Use Peer code review, if possible pre-commit reviews. Peer code review is a key element in building a robust and egoless engineering culture of collaborative problem-solving ([source](https://semaphoreci.com/blog/cicd-pipeline))
 * If you change the principles/systems/processess, do it incrementally. Developer productivity matters a lot. Minimize friction. e.g don't do a migration of all CI/CD Ecosystem in a way that breaks everything for a while. Do it step by step, phase the changes. Make it possible to rollback easily to previous working state.
 * Quality first. If you’re doing CI and for some reason the integration fails, that means the broken build becomes the highest priority to fix before continuing to add more features. System quality—not just velocity—is important. CI works in three simple stages: push, test, and fix. But despite this simplicity, CI might become challenging if only a few members of the team practice it. Consequently, CI also requires a change in culture and support from management. [source](https://stackify.com/what-is-cicd-whats-important-and-how-to-get-it-right/)
+* Refactoring can only truly begin once you've actually learned what a piece of code or some data structure did, the unique properties for which they were written or chosen. Anything else is setting yourself up for failure. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html)
+* It also means that when building systems, you should not assume that operators will do things correctly. Expect failure from people. Try to think about tools you can give them to undo their mistakes, because they will happen sooner or later. Have some dread. Be understanding. Know things won't be perfect. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html)