As tu un problème d’Ego ?

As tu la grosse tête ? Le melon ?

As tu les chevilles qui gonflent ?

Peut-être que tu t’ai mis à la programmation et que tu viens de te rendre compte de ton super pouvoir ?

Peut-être que tu es fréquemment sollicité sur LinkedIn, ou sur les plateformes de freelance ?

Tu sens que le monde a besoin de toi.

Tu es même peut être déjà en poste et on fait appel à toi pour résoudre des problèmes urgents, graves.

Sans toi la terre s’arrêterait de tourner non ?

C’est un problème qui arrive dans de nombreux secteurs.

Mais surtout dans l’informatique.

Certains développeurs ont un égo surdimensionné.

Mais avant de parler d’égo je te colle une définition de l’internaute , car tout le monde a une vision plus ou moins différente de l’égo.

« Ego désigne le moi, c’est-à-dire la représentation et la conscience que tout individu à de lui-même.

Exemple : Les réseaux sociaux permettent d’entretenir un certain ego et de raconter sa vie à qui veut l’entendre ! 
»

Pourquoi de nombreux développeurs ont ce problème d’égo ? 

Car il faut dire la vérité !

Bien évidemment il est déconseillé de rester longtemps sur les même projets, les mêmes missions et les mêmes technos. 

Mais le développeur est humain, il aime sa zone de confort !

La plupart reste sur des projets de nombreuses années, dans la même boite à faire les mêmes choses.

Ces développeurs se sentent de plus en plus à l’aise, de plus en plus productif, et on fait de plus en plus appel à eux.

Mais surtout ils se sentent de plus en plus indispensables à cause de la rareté des profils.

Leurs égo grandit …

Mais on pourrait aussi y ajouter un autre biais cognitif des développeurs qui se sentent supérieurs.

L’effet de Dunning-Kruger, ou effet de surconfiance.

C’est un biais cognitif selon lequel les moins qualifiés dans un domaine surestiment leur compétence.

Personnellement je le positionnerais vers 1 à 3 ans d’expériences.

C’est un peu l’inverse du syndrome de l’imposteur dans lequel on manque complètement de confiance alors que pourtant on a les compétences.

Ici on a une surconfiance, par rapport aux compétences réelles.

Alors pourquoi je te parle de tout cela ?

Non pas pour briser le peu de confiance que tu peux avoir quand si tu débutes.

Ni pour pour te faire remarquer que peux être tu surestimes tes compétences.

C’est juste pour que tu sois conscient de ces phénomènes.

Ils ont de fortes chances de se produire un jour dans ta carrière de développeur.

Autant être au courant.

Mais c’est aussi pour te prévenir que cela induis de mauvaises habitudes …

Ainsi que de mauvaises croyances et de mauvais comportements.

Ce problème d’égo pousse les développeurs à ne pas poser de questions techniques de peur de passer pour un incompétent.

Cela pousse les développeurs à avoir un état d’esprit moqueur envers le code des autres. 

Tu n’imagines pas le nombre de fois où j’ai vu ça à la machine à café ! Et j’y ai probablement déjà participé …

Ce problème d’égo ne poussent pas les développeurs à l’entraide. 

Soit tu es bon, soit tu es nul ! Et si tu es nul tu es exclu au lieu d’être poussé vers le haut. 

Ce problème d’égo fait que tu n’oses pas montrer ton code de peur d’être jugé, analysé, critiqué. 

Alors que c’est en faisant des revus de code que l’on progresse le plus.

Ce problème d’égo fait que si tu vois un développeur meilleur que toi, tu vas soit t’écraser comme une merde, ou soit aller bêtement à la confrontation. 

Tout cela va à l’encontre des qualités attendu d’un développeur selon le Software Craftsmanship Manfiesto

Qualité, Humilité, Partage, Pragmatisme, Professionnalisme

Je vais te donner 10 règles pour coder SANS EGO.

Ces 10 règles sont issues du livre « The Psychology of Computer Programming” (Jerry Weinberg, 1971).

1/ Understand and accept that you will make mistakes

Si tu penses que tu vas sortir d’une école, d’une formation et coder sans faire d’erreur tu rêves …

Tous les développeurs, expérimentés ou non font des erreurs, c’est tout à fait normal.
 2/ You are not your code

Quand on critique la qualité de ton code ça peut faire mal. 

Mais ce n’est pas toi qui est attaqué, c’est le code. Il faut se détacher du code que l’on produit.
 3/ No matter how much « karate » you know, someone else will always know more

Il y a toujours un développeur meilleur que nous et bien heureusement.
 4/ Don’t rewrite code without consultation

Voir du code poubelle peut parfois agacer. On a parfois envi de tout réécrire.

Le faire sans avoir un échange avec la personne est une perte d’opportunité de s’améliorer.

Mais cela va aussi probablement pourrir les relations entre les 2 développeurs.
 5/ Treat people who know less than you with respect, deference, and patience

On est souvent sur des projets avec des développeurs ayant des niveaux, des expériences différentes. 

Si tu as 10 ans de Java est que tu bascules sur du Node JS, tu es un débutants.

Tu n’aimerais pas te faire incendier à la moindre erreur ?

Et bien c’est pareil avec les petits nouveaux. Reste humble et patient.
6/ The only constant in the world is change

Ne sois pas résistant au changement, c’est perdu d’avance ..
 7/ The only true authority stems from knowledge, not from position

La connaissance engendre l’autorité et l’autorité engendre le respect.

Donc si tu veux le respect dans un environnement sans ego, cultive la connaissance.
 8/ Fight for what you believe, but gracefully accept defeat

Il faut toujours défendre ses idées …

Mais parfois elles seront rejetées.

Même si tu as raison, il ne faut pas avoir de rancune et passer à autre chose.
 9/ Don’t be « the guy in the room »

Ne soit pas le mec chelou qui code toute la journée dans sa cave, qui ne parle avec personne, et s’en fou de l’équipe.
10/ Critique code instead of people – be kind to the coder, not to the code

Il ne faut pas critiquer un développeur sur sa personne. On se respecte entre développeur, on est sympa entre nous.

Mais par contre le code peut tout à fait être critiqué !
J’espère que ces conseils pourront t’aider à ne pas emprunter un mauvais chemin  … 

À bientôt,
Mike

Un commentaire