I can check the boxes 😧

Short but well explained. Hell of these 4 arguments. There are true !

1. Comprendre ce qu'on fait [Simple, basique, mais c'est un prérequis]
2. Connaître plusieurs paradigmes permet de résoudre un problème avec de meilleures
3. On ne transige pas avec la qualité de son programme en production, et on s'en fout de la qualité lors de résolution du problème : il faut prototyper jusqu'á trouver une solution qui fonctionne.
4. Prendre le temps de lire ce qui est mis à disposition (erreurs, documentation entre autres).

Plein de bons conseils !

Parfois je ressens cela en entreprise 😧

TL;DR; un module, une fonction => une tâche

Approuvé !

Comparer les salaires:

• Glassdoor
• Indeed

Jouer le jeu des négociations :

• Toujours être en position de force. Si le poste m’est refusé, rien à foutre, next.
• Toujours demander plus haut que ce que je veux. Car mon interlocuteur a de toute façon prévu de me donner plus bas.

Investir sur soi, apporter plus de valeur et gérer les entretiens techniques, même si ils ne rṕondent pas aux compétences du poste.

I can't say this enough.

You will read code more than you write code.

Learn to get good at it.

La loi de Gall :

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

TL,DR
Make fun with personal project. Even if the project already exists, make what you like. It can be of any size, smaller or bigger as wanted. Because you can. And it always be useful.

Success in programming :

producing high quality code2, either by oneself or as part of a team, that helps to solve some problem for an end user

and about general programmers :

However, I believe for a lot of professional programmers, succeeding comes from focusing on not “losing points” - causing bugs or producing unfathomable code, for example.

1. Clean Code
2. Soft Skills: The software developer's life manual
3. Deep Work

• pour le JS : Secret of the Javascript Ninja
• pour les design patterns : Head first design patterns
• pour les entretiens techniques : Cracking the code interview

So there is four stages of quality for each name :

• Nonsense : For example, we might extract a method from a larger one and quickly rename it somethingWhatever() to get the refactor done and the tests passing.
• Accurate : We rename the nonsense method to what it actually does, such as processPayroll()
• Precise : Once we realise what the method really does, we might refine the accurate name and give it more precision, such as loopThroughEmployeesAndPayThem().
• Meaningful : At this point, we’ve revealed the complexity of the method, and can look to split it up into two methods: forEachEmployee() and perhaps a payWages() method on a separate interface.

I always use at least accurate names, because it helps me even during the development process. Something I tend to is to use meaningful names and thus creating a lot of functions 😅
I dislike the precise one as it looks as a function that need to be changed, because of doing to much things. At least, this reveals the complexity behind the name.

É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 😞