The key, as Rother suggests, is that it wasn’t the tools that made Toyota great, it was the culture and specific behavior associated behind those tools.

==> As said by other smart persons :
- Don't fix bugs, fix your process.
- Don't work harder, work smarter.

The "Let it crash" principle reminds me of the Unix's "Rule of Repair" (https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html) : "When you must fail, fail noisily and as soon as possible."

Plein de bons conseils, malheureusement souvent mis en pratique :-/

L'ensemble de l'article est aussi vrai que drôle.
Mention spéciale à cette phrase qui a un petit goût de "j'ai-déjà-vu-ça-quelque-part" :

Dans le désordre tu peux obliger tout le monde à travailler minimum 60 H par semaine. Quand les gens n’auront plus de vie personnelle, c’est avec plaisir non dissimulé qu’ils vont chier à l’intérieur de ton projet.

"Cleaner" does not mean "more efficient" : have a look at the urban planner's dream pizza to get the idea (well, read the article too ;-)

Scott’s Law: never put order in a system before you understand the structure underneath its (apparent) chaos.

1. Ability to ignore new tools and technologies
2. Taste for simplicity
3. Good code deletion skills
4. Humility

Ne pas changer les méthodes de travail pour favoriser l’adoption

Transformer son smartphone en coffre-fort peut être contre productif
==> les coups et la torture viennent toujours à bout des mots de passe

Pretty interesting article about "spaghetti code" and (specific!) situations where you've left with no choice but spaghetti code.

Seen in the comments :

"(...) essential and accidental complexity. Once you have got rid of the accidental complexity, you are left with the essential complexity, which cannot be further reduced without compromising on functionality.
You can shovel the essential complexity around your system design all you like, but the overall quantity of complexity still remains constant."

Assholes are a disease that spreads through your organization, slowly killing it from the inside. Yet, employing assholes is one of the most common mistakes I see tech companies make, because they are so laser-focused on hiring people with technical skills that those skills become the sole determiner of an engineer’s value.

So how do you know if someone is an asshole? Here’s a simple test: if someone walks away from another person feeling bad about themselves, they were probably interacting with an asshole. Assholes undermine your confidence, they talk down to you, they try to make themselves look good at your expense, and they generally make you regret having to talk to them.

When you learn something from a non-asshole you walk away thankful for the mentorship.

assholery can have cascading effects where eventually everyone is being an asshole to each other.

Asshole behavior at work can cost companies millions of dollars a year in lost productivity, drained morale, employee loyalty, and worker commitment.

asshole behavior packs 5 times the impact as non-asshole behavior, so reaching only a 20% asshole population results in an oppressive, miserable work environment that cannot be fixed, only escaped.

Job requirements rarely specify social skills as an essential task, so HR often won’t get on board with letting someone go for being an asshole unless they commit some outrageous act of harassment. Formalizing social skills as part of the job description can help with this.

They (assholes) become the “experts” in particular areas of code (...). This results in a situation where assholes are deemed too important to lose, and the thought of just losing all of the assholes in the organization feels like losing your “best” people and a surefire way to destroy your company. Be assured that if you feel like you can’t “afford” to lose all of your assholes, your organization has been overrun by assholes.

Creating an asshole-free work environment is actually very straightforward, all it takes is a commitment to following a few steps. (...) you need to decide, as an organization, you’re not going to tolerate assholes. (...) Simply being explicit is often enough.

There is no question you can think of to determine if someone is an asshole that would not be trivially easy for a self-aware asshole to lie through. Don’t even bother trying.


So also some interesting comments :
- https://news.ycombinator.com/item?id=20359378#20360747 : "People with Asperger's or otherwise on the autism spectrum can be huge "assholes" by the definitions here. Does autism make you unemployable?"
- https://news.ycombinator.com/item?id=20359378#20360341 : At least 10 thousand years of civilization, and we are still trying to figure out each other and ourselves. Why is "Don't be a dick" so hard to codify?

« Si un accident se produit, l’important n’est pas de savoir qui a fait une faute, mais d’identifier pourquoi et comment le système de sécurité a failli ».

==> aka l'effet "alignement des trous du gruyère"

1. Understand and accept that you will make mistakes.
2. You are not your code.
3. No matter how much "karate" you know, someone else will always know more.
4. Don't rewrite code without consultation.
5. Treat people who know less than you with respect, deference, and patience.
6. The only constant in the world is change.
7. The only true authority stems from knowledge, not from position.
8. Fight for what you believe, but gracefully accept defeat.
9. Don't be "the guy in the room."
10. Critique code instead of people – be kind to the coder, not to the code.