diff --git a/knowledge base/best practices.md b/knowledge base/best practices.md index 5d824e8..9cb6ddc 100644 --- a/knowledge base/best practices.md +++ b/knowledge base/best practices.md @@ -26,10 +26,16 @@ What really worked for me. implement.
Things change constantly: new technologies are given birth often, and processes improve. Also, now you know better then before. +- Focus on the real problem at hand.
+ Beware the [the XY problem]. +- Do not make things more complicated than they **need** to be. - 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]. +- Stop modularizing stuff just to [avoid repetitions][don't repeat yourself(dry) in software development]. +- Stop [abstracting away][we have used too many levels of abstractions and now the future looks bleak] stuff that does + not need to be (`docker-cli`/`kubectl` wrappers mapping features 1-to-1, anyone?). - Beware of complex things that _should be simple_.
E.g., google what the _[SAFe] delusion_ is. - Focus on what matters, but also set time aside to work on the rest.
@@ -37,15 +43,15 @@ What really worked for me. - Learn from your (and others') mistakes.
Check out the [5 whys] approach. - 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]. +- Automate when and where you can, yet mind [the automation paradox] and + [abstractions][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. + templates and pipelines.
+ Stop designing systems that _should work for everybody at all times_. - 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.
@@ -70,7 +76,8 @@ What really worked for me. They are **not** to be taken literally.
They **need** to be adapted to the workplace, not the other way around. - [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. + They are generally good practices, but only Amazon is able to apply them as they are defined **and** they still create + a lot of discontent when used against people. - Keep Goodhart's law in mind: > When a measure becomes a target, it ceases to be a good measure. @@ -154,6 +161,8 @@ Listed in order of addition: - [Why your platform monolith is probably a bad idea] by David Leitner - [How to mind Goodhart's law and avoid unintended consequences] - [The XY problem] +- [Don't repeat yourself(DRY) in Software Development] +- [Wisdom From Linus - Prime Reacts]