Évidemment que la qualité c’est important, évidemment que tu dois t’en préoccupé et évidemment tu dois déployer des applications de production qui sont de qualité. Évidemment ! Mais le problème de la qualité c’est que ça prend du temps. [...] la qualité c’est ton objectif, pas ton point de départ

Je me retrouves tellement dans les paragraphes suivants !!!

À chaque fois qu’on me demande quelque chose que ce soit un projet entier ou juste une petite tache isolée ce que je fais c’est que je me concentre sur le problème principal. Quel est le problème principal ? Comment je peux réduire le problème pour avoir juste le coeur du problème, le coeur de ce que je dois résoudre en fait.

Je me concentre dessus et je le fais fonctionner le plus rapidement possible, sans me préoccuper de la qualité, pas tout de suite ! Je ne pense pas à ou est-ce que ça va être, je pense pas comment ça va être, je pense pas à comment je vais l’intégrer avec tout un système, je pense à d’abord régler le plus petit problème.

Et je pourrais citer toutes la partie Make it work en fait 💬

Une fois que le prototype marche, écrire les tests et refactoriser/réécrire pour que ce sois de la qualité 👍

So, if you want to contribute to open-source — as a whole — here are my tips:

• Find problems which you are intrinsically motivated to work on.
• Focus on developing skills to get up to speed on new codebases fast.
• Don’t be afraid to work on any project — new languages, tools, libraries; learn enough of them and it’ll only get easier to learn more.
• When you file bug reports with a FOSS project, get into the habit of following up with a patch which addresses the problem.
• Get used to introducing yourself to maintainers and talking through the code; it always pays to ask.

Recommendation: In performance-sensitive code, you should avoid creating or copying thousands or millions of non-trivial objects.

In javascript, it is sometimes hard to avoid that 😞

A list of naming conventions grouped by languages ❤️

It’s clear to me now that it's not about what I know, but rather how I think that's different on these days.

So the two questions for me are: (1) How can I have more good days than bad ones? And, (2) what exactly am I doing differently on my good days?

About relative deprivation

Top students convincing everyone else to stop trying. Or, great engineers convincing the rest to stop trying.

This is ego distraction in action. Self comparison determining effort. If we feel like we’re ahead we continue to put in the effort. If we feel like we’re not, we determine it’s not worth the effort.

About ego

The Ego's trick is always the same. Make it personal. Make it about me. Put me at the center. So when we sit down to solve a problem the trick is to only ask ourselves problem related questions. These are "the" or "what" type questions. We must avoid asking the personal "I" or "me" type questions. So instead of thinking "Did I cause the bug?", we instead ask "Where is the bug?".

Wow ! C'est propre tout ça.

J'aime beaucoup les trois premières, peut-être parce qu'elle concerne surtout soi-même et c'est ce qui me concerne le plus actuellement. Les ADRs me semblent aussi très utiles sur le long terme !

1. Le Brain Dump 🧠
2. La méthode Mikado 🥢
3. L'over-comitting ➿
4. Les Architecture Decisions Records (ADR) 📝
5. Le Approval Testing ✅
   1. Générer un output capturable dudit code dans un test
   2. Utiliser la couverture de tests pour trouver toutes les combinaisons
   3. Introduire des mutations pour vérifier la qualité des tests
6. L'analyse de Hotspots
7. Les katas

It seems there are two common ways how Open Source projects die: either the maintainer simply loses interest and abandons the project or they decide that the project became so complex that it needs a complete rewrite. Joel Spolsky wrote an article nearly 20 years ago on how that's generally a bad idea.

L’eau, le feu, la terre, le vent et Javascript.

🤣

Des réflexions pertinentes :

Du coup, c’est quoi l’adaptabilité ? Pour un dev, ça va être la capacité à pouvoir être mis sur des projets aux technologies différentes ou dans un contexte métier compliqué (bancaire, santé) avec des règles contraignantes.

Comprenons-nous bien l’échec est inévitable, c’est une partie du processus, et il va revenir.
La persévérance, c’est continuer, échouer, recommencer, jusqu’à la réussite.

Enfin bref, un bon article pour débuter :)