From b87b3e0b55ed9ca0e7260e2601b3914f9b00679f Mon Sep 17 00:00:00 2001 From: Morgan Date: Sun, 24 Jan 2021 12:21:57 +0100 Subject: [PATCH] additional principle for slow programming --- PRINCIPLES.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index e065ace..fab15ff 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -249,8 +249,8 @@ See also [Calm programming / Slow programming](README.md#calm-programming--slow- * If possible, don't branch, work on trunk/main. Branching/Feature flags can help. * 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/) +* Quality first | Quality is always right. 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) * Study your tools, see how you work, understand how you can improve it. Don't rush. Before you run, you have to learn to walk. - +* Wait before jumping on every opportunity/request/problem. Don’t touch it / don’t act too soon