Avantages des plateformes de programmation compétitives:

• fun (mais on peut avoir du fun tout en faisant un truc plus utile)
• amélioration de la logique algorithmique
• préparation aux entretiens techniques

Ça va être très dur au début. Ça fait un choc à beaucoup de monde.

Silicon Valley-like companies think of engineers as value generators, and creative problem solvers. Traditional companies think of them as factory workers.

Par contre, se comparer à soi-même est vitale. La clef c’est d’avoir une façon de penser tournée vers l’amélioration continue. Ton seul niveau de référence étant le tien. Le toi du passé.

“Tu peux pas tout savoir. Par contre, c’est bien de savoir ce que tu sais pas.”

L’excellence nécessite forcément énormément de travail.

Tourner le syndrome de l'imposteur en avantage: un prise de notes régulières afin de sortir des vagues sentiments et d'avoir la réalité en face.

• Ce que tu sais et ce que tu as réussi
• Ce que tu veux apprendre

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.