diff --git a/knowledge base/best practices.md b/knowledge base/best practices.md index c76c462..3bc6428 100644 --- a/knowledge base/best practices.md +++ b/knowledge base/best practices.md @@ -3,6 +3,7 @@ What really worked for me. 1. [Generic concepts](#generic-concepts) +1. [Teamwork](#teamwork) 1. [CI/CD specific](#cicd-specific) 1. [Pipelining](#pipelining) 1. [Product engineering](#product-engineering) @@ -10,28 +11,31 @@ What really worked for me. ## Generic concepts -- Always think critically.
- If you do/think things just bEcAuSe OtHeRs SaId So, all you're doing is admitting **both** that you know no better **and** that you're not willing to consider otherwise. -- The _one-size-fits-all_ approach is a big fat lie.
- You'll end up with stiff, hard to change results that satisfy nobody. This proved particularly true with regards to templates and pipelines. -- Apply the KISS approach wherever possible.
- Consider it not as _keeping all things simple because they need to be simple_, but as an invite to keep things simple **with respect of your ultimate goal**.
- Beware of simplicity for the sake of simplicity, specially if this makes things complicated on a higher level. Check out [KISS principle is not that simple]. -- Beware of complex things that sHoUlD bE sImPlE.
- Check out the [SAFe] delusion. +- Always think critically and question all the things. Especially those that don't appear to make any sense.
+ Don't just follow trends or advice from others. They _might_ know better, but you will be the one dealing with the issues in the end. +- Try to understand how something really works, may it be a technology, a tool or what else.
+ Try at least once to do manually what an automation saves you. Look at the source code of tools. Read the fabulous documentation. +- Stay curious. Experiment. Learn and break things (in a sane and safe way). Dive deeper into what interests you. - There is no perfect nor correct solution, just different sets of tradeoff.
Find the one that most satisfies you and your **current** necessities. - Review every decision after some time. Check they are still relevant, or if there is some improvement you can implement.
Things change constantly: new technologies are given birth often, and processes improve. -- Focus on what matters, but also set time aside to check up the rest.
+- Keep things simple (KISS approach) **with respect of your ultimate goal** and not only for the sake of simplicity.
+ Always going for the simple solution makes things complicated on a higher level.
+ Check out [KISS principle is not that simple]. +- Beware of complex things that _should be simple_.
+ E.g., [SAFe]. +- Focus on what matters, but also set time aside to work on the rest.
Check [Understanding the pareto principle (the 80/20 rule)]. -- Learn from your (and others') mistakes. -- Put in place processes to avoid repeating mistakes.
+- Learn from your (and others') mistakes.
Check out the [5 whys] approach. -- Automate when and where you can, yet mind [the automation paradox].
- Check also out [`pre-commit`][pre-commit]. -- Keep things **de**coupled where possible, the same way [_interfaces_ are used in programming][what does it mean to program to interfaces?].
+- Put in place processes to avoid repeating mistakes. +- Automate when and where you can, yet mind [the automation paradox]. +- Automation does **not** necessarily involve [abstracting away][we have used too many levels of abstractions and now the future looks bleak]. +- Keep different parts **de**coupled where possible, the same way [_interfaces_ are used in programming][what does it mean to program to interfaces?].
This allows for quick and (as much as possible) painless switch between technologies. +- The _one-size-fits-all_ approach is a big fat lie.
+ You'll end up with stiff, hard to change results that satisfy nobody. This proved particularly true with regards to templates and pipelines. - Choose tools based on **how helpful** they are to achieve your goals.
Do **not** adapt your work to specific tools. - Backup your data, especially when you are about to update something.
@@ -46,15 +50,25 @@ What really worked for me. - [Trunk-based development][trunk-based development: a comprehensive guide] and other branching strategies all work.
Consider the [different pros and cons of each][git branching strategies vs. trunk-based development]. - Refactoring _can_ be an option.
- Just **don't** use it mindlessly. + Just **don't default** to it nor use it mindlessly. +- Be aware of [corporate bullshit][from inboxing to thought showers: how business bullshit took over]. - _DevOps_, _GitOps_ and other similar terms are sets of practices, suggestions, or approaches.
They are **not** roles or job titles.
They are **not** to be taken literally.
They **need** to be adapted to the workplace, not the other way around. -- Be aware of [corporate bullshit][from inboxing to thought showers: how business bullshit took over]. - [Amazon's leadership principles] are double-edge swords.
Only Amazon was able to apply them as they are defined, and they still create a lot of discontent. +## Teamwork + +- Respect what is already there, but strive to improve it.
+ Current solutions are there for a reason. Learn about their ins and outs **and, most of all, the why**.
+ Then try to make them better. +- Don't just dismiss your teammates' customs.
+ E.g., use [EditorConfig] instead of your editor's specific setting files only. +- You, your teammates and other teams in your company _should be_ on the same boat and _should be_ shooting for the same goal.
+ Act like it. You may as well collaborate instead of fighting. + ## CI/CD specific - Keep _integration_, _delivery_ and _deployment_ separated.
@@ -71,6 +85,8 @@ What really worked for me. Avoid like the plague to put programs or scripts in pipelines: they should be _glue_, not replace applications. - All tasks should be able to execute from one's own local machine.
This allows to fail fast and avoid wasting time waiting for pipelines to run in a blackbox somewhere. +- Consider using local automation to guarantee basic quality **before** the code reaches the shared repository.
+ Tools like [`pre-commit`][pre-commit] are a doozy for this. - DevOps pipelines are meant to be used as **last mile** steps for specific goals.
There **cannot** be a single pipeline for everything, the same way as the _one-size-fits-all_ concept never really works. @@ -117,6 +133,7 @@ In order of addition: --> +[editorconfig]: editorconfig.md [pre-commit]: pre-commit.md [safe]: safe.placeholder [the automation paradox]: the%20automation%20paradox.md