Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Êtes-vous un développeur sans égo ?
Vous reconnaissez-vous dans les 10 commandements de la programmation sans égo ?

Le , par Hinault Romaric

0PARTAGES

11  2 
Le programmeur est souvent considéré dans la société comme une personne asociale, qui reste assise à longueur de journée devant un écran, et qui n’accepte pas que son travail soit critiqué.

Le concept de la programmation sans égo a pour but d’améliorer la qualité du code, en faisant passer en revue le code par d’autres programmeurs, en insistant sur le fait que ces revues soient faites dans un esprit amical, collégial, en laissant de côté les sentiments personnels.

En s’inspirant du livre « The Psychology of Computer Programming » de Jerry Weinberg, Jeff Atwood, illustre blogueur et créateur du site Stack Overflow, énonce et commente les dix commandements de la programmation sans ego :

  1. Comprenez et acceptez que vous alliez faire des erreurs. Pour Atwood, les erreurs sont rarement mortelles dans l’industrie du développement. Ainsi, nous devrons apprendre, rire et progresser de nos erreurs.
  2. Vous n’êtes pas votre code. Rappelez-vous que le but de la revue d’un code est de trouver des problèmes, et des problèmes seront trouvés. Ne les prenez pas personnellement lorsqu’ils sont découverts.
  3. Peu importe le nombre de « karatés » que vous maitrisez, quelqu’un d’autre en saura toujours plus que vous. Un tel individu peut vous apprendre quelque chose de nouveau. Recherchez et acceptez l’avis des autres, surtout lorsque vous pensez que ce n’est pas nécessaire.
  4. Ne pas réécrire le code de quelqu’un sans le consulter. Il y a une ligne fine entre « code de fixation » et « réécriture du code ». Il est indispensable de connaitre cette différence et d'éviter de foncer tout seul dans son coin.
  5. Traitez les gens qui savent moins que vous avec respect, déférence et patience. Les personnes non techniques qui traitent avec les développeurs régulièrement trouvent ceux-ci pleurnichards. Atwood invite à ne pas renforcer ce stéréotype de colère et d’impatience.
  6. La seule constante dans le monde est le changement. Soyez ouvert et acceptez cela avec un sourire. Percevez chaque changement (outils, besoins, plateformes, etc.) comme un nouveau défi.
  7. La seule véritable autorité acceptable découle de la connaissance et non du pouvoir. La connaissance engendre l’autorité, et l’autorité suscite le respect. Si vous voulez du respect, cultivez le savoir.
  8. Il faut se battre pour ses idées, mais accepter gracieusement la défaite. Acceptez que, parfois, votre raisonnement ne soit pas suivi. Même si plus tard il s’avère juste, il ne sert à rien de remettre sur le tapis le « Je vous l’avais bien dit ».
  9. Ne pas être « le gars dans la chambre ». Être hors de contact, hors de vue et hors de contrôle n’a pas sa place dans un environnement ouvert et collaboratif.
  10. Critiquer le code plutôt que la personne. On peut être gentil avec la personne tout en commentant le code. Autant que possible, faire des commentaires positifs et orientés vers l’amélioration du code. Par exemple, les commentaires relatifs aux normes, standard, spécifications, performances sont toujours bien perçus.


Voilà des règles « universelles » qui sont probablement appliquées par de nombreux développeurs.

Source : Coding Horror

Et vous ?

Êtes-vous un développeur sans égo ?

Vous reconnaissez-vous dans ces commandements ?

Quelles autres règles proposez-vous pour le développeur sans égo ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 03/01/2014 à 18:30
Je suis suis pas un développeur sans égo, je suis un développeur sans égal

23  0 
Avatar de AlexRNL
Membre habitué https://www.developpez.com
Le 03/01/2014 à 21:11
Citation Envoyé par SylvainPV Voir le message
Je plaide coupable pour ne pas respecter plusieurs de ces points. Par exemple, ça m'arrive de réécrire du code d'autres personnes sans les consulter. Mais c'est peut-être parce que certaines de ces personnes ont elles aussi leur égo et refusent d'admettre avoir tort. C'est d'autant plus difficile lorsque ces personnes ont dix ans de plus que moi... dur de se faire corriger par le petit jeune.

Je suis bien placé pour savoir que c'est assez mal vu lorsque quelqu'un ramène perpétuellement sa science. A l'école mes profs m'appelaient Monsieur je sais tout, parce que j'adorais les corriger lorsqu'ils se trompaient. Ponctuellement ça va, mais à la longue je passe au mieux pour un perfectionniste, au pire pour un emmerdeur prétentieux.

Alors est-ce qu'il ne vaut pas mieux parfois faire quelques modifs en douce, plutôt que de critiquer sans cesse (et même une critique constructive reste une critique). C'est le seul moyen que j'ai trouvé pour rester humble et apprécié sans laisser passer trop d'énormités dans le code.
C'est peut-être toi qui a tort, non ?

Perso, je ne repasse jamais sur un code que je trouve étrange/bizarre/faux sans chercher à savoir pourquoi ça a été fait comme ça (donc en allant voir la personne qui a fait les modifications). Parce que dans la plupart des cas, la raison n'est pas l'incompétence de l'auteur, mais des contraintes qui sont peut-être toujours d'actualité.
16  1 
Avatar de psykokarl
Membre confirmé https://www.developpez.com
Le 04/01/2014 à 3:38
Haaaa! Le developpeur sans ego, Le graal du recruteur, à la fois efficace et aussi interchangeable qu'un écrou dans un meuble en kit Ikea.
Il faut dire que c'est gênant de travailler avec des égos, qui s’approprient ce qu'ils font, qui le prennent mal quand on leur marche dessus, qui ne tiennent pas à la place qui leur est assigné.

Bien-sur ces commandements ne sont pas valables pour le management ou les entreprises. Si le gars en bout de chaine doit assumer des retard accumuler en amont du en partie par des impondérables néanmoins pondérer par une estimation de délais sortie de sous le chapeau, il doit accepter les critique sur son boulot dans un esprit de franche camaraderie et surtout ne pas remettre en question les process. Il faut s'adapter.

Je confesse. Je suis un développeur avec égo et fier de l'être.
En fait j'ai du développer mon égo parce que le monde du travail, c'est des interagir avec gens et certains essaieront de vous écraser si vous être trop malléable, trop sympa, trop concilliant. Bref sans égo.

Citation Envoyé par Hinault Romaric Voir le message
  1. Comprenez et acceptez que vous alliez faire des erreurs. Pour Atwood, les erreurs sont rarement mortelles dans l’industrie du développement. Ainsi, nous devrons apprendre, rire et progresser de nos erreurs.
    C'est largement compris et accepté pour ma part. Après il faut que l'encadrement le comprenne. Les convaincre parfois de l'utilité des test unitaires et autres précautions qui n'apportent pas de valeur ajouté au produit fini.
  2. Vous n’êtes pas votre code. Rappelez-vous que le but de la revue d’un code est de trouver des problèmes, et des problèmes seront trouvés. Ne les prenez pas personnellement lorsqu’ils sont découverts.
    Ca dépend aussi de comment l'info remonte et comment l'erreur est perçue par celui qui la découvre. C'est pas pour mettre la pression mais si le code est pourri, ce n'est pas le code qu'on vire et c'est plutôt mal vu de ne pas prendre les choses personnellement. Si vous êtes de nature impassible prenez des cours de théâtre pour montrer un minimum d'accablement.
  3. Peu importe le nombre de « karatés » que vous maitrisez, quelqu’un d’autre en saura toujours plus que vous. Un tel individu peut vous apprendre quelque chose de nouveau. Recherchez et acceptez l’avis des autres, surtout lorsque vous pensez que ce n’est pas nécessaire.
    C'est pas aussi simple. Un avis extérieur est toujours le bienvenu mais c'est contrebalancé par le fait l'avis extérieur n'est pas au fait des contraintes concernant le cas en question.
  4. Ne pas réécrire le code quelqu’un sans le consulter. Il y a une ligne fine entre « code de fixation » et « réécriture du code ». Il est indispensable de connaitre cette différence et éviter de foncer tout seul dans son coin.
    Et si la tache consistante a réécrire. Tache assignée par une personne qui n'a pas écrite le code et qui ne sait pas comment joindre celui qui a écrit le code à supposé que cette personne soit joignable et disponible (quid du manuel de dev dans un contexte de turnover important)
  5. Traitez les gens qui savent moins que vous avec respect, déférence et patience. Les personnes non techniques qui traitent avec les développeurs régulièrement trouvent ceux-ci pleurnichards. Atwood invite à ne pas renforcer ce stéréotype de colère et d’impatience.
    Les personnes non techniques n'ont souvent aucune idée de la quantité de boulot que demande une modification qui leur parait simple. A contrario un détail assez évident pour être omis par un fonctionnel ne l'est pas forcément pour un développeur.
    Pour peu que la personne non technique se montre impatiente et demande de modifier un truc important vers la fin de la phase de compilation.
  6. La seule constante dans le monde est le changement. Soyez ouvert et acceptez cela avec un sourire. Percevez chaque changement (outils, besoins, plateformes, etc.) comme un nouveau défi.
    En effet, il n'y a aucune raison de grincer les dents à l'idée de remettre en question un système fiable et éprouvé pour mettre en place la nouvelle usine à gaz à peine déplâtrée mise au point par des dev qui n'ont aucune connaissance des contraintes liées à votre environnement de travail mais dont la critique dans la presse est élogieuse.
  7. La seule véritable autorité acceptable découle de la connaissance et non du pouvoir. La connaissance engendre l’autorité, et l’autorité suscite le respect. Si vous voulez du respect, cultivez le savoir.
    Dans certaines boites, le penser trop fort est un coup à perdre son boulot . En généralement les deuxièmes pouvoirs sont plutôt mal vu. C'est celui qui paie qui commande.
  8. Il faut se battre pour ses idées, mais accepter gracieusement la défaite. Accepter que parfois, votre raisonnement ne soit pas suivi. Même si plus tard, il s’avère juste, il ne sert à rien de remettre sur le tapis le « Je vous l’avais bien dit ».
    Le combatif par définition a du mal a admettre la défaite. Dans "force de proposition" le mot important c'est "proposition" et non "force".
  9. Ne pas être « le gars dans la chambre ». Être hors de contact, hors de vue et hors de contrôle n’a pas sa place dans un environnement ouvert et collaboratif.
    Il y a contrôle et contrôle. On peut avant ou après chaque cycle dire ce que l'on fait mais en général dire comment on le fait, pourquoi on le fait et comment cela fait n'intéresse pas grand monde en général en dehors de l'équipe en général
  10. Critiquer le code plutôt que la personne. On peut être gentil avec la personne tout en commentant le code. Autant que possible, faire des commentaires positifs et orientés vers l’amélioration du code. Par exemple, les commentaires relatifs aux normes, standard, spécifications, performances sont toujours bien perçus.
    Bon je ne dirais rien sur celle ci. Il faut dire que par moment je frise la mauvaise foi (je frise seulement).
Ce qu'il faut retenir de ce dernier point ainsi que de tout les autres est l'importance de la communication et on communique avec des égos. Des gens non interchangeables qu'il faut apprendre à connaitre pour ne pas faire de boulette. Il faut parfois arrondir les angles, parfois se montrer ferme, savoir quand on peut faire des remarques et savoir quand on doit acquiescer sans rien dire. Des choses évidente mais faciles à oublier quand la compétition devient le moteur d'une entreprise.
10  2 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 04/01/2014 à 0:32
Moi, ce que je ne supporte pas c'est quand on mésestime mes compétences. Genre sur un projet, on ne me consulter pas alors que j'avais annoncé avoir la compétence pour répondre, et on va consulter une autre personne qui n'a même pas la compétence. C'est franchement frustrant, mais ça m'est arrivé qu'avec un seul type qui ne m'a jamais adressât la parole si ce n'est pour m'annoncer les problèmes. Mais j'ai l'impression qui faisait ça avec tous les nouveaux venus, sauf qu'au bout d'un c'est lourd.

Sinon ça m'est déjà arrivé de critiquer le code de personne qui n'était plus dans la boîte, et ces personnes n'avaient clairement rien à faire dans le dév. Sinon ça ne sert à rien de dire qu'il fait « de la merde », il vaut mieux lui expliquer ce qui ne va pas, même si ce n’est pas forcement facile à faire... Il faut être un peu pédagogue, et on voit que ce n’est pas donné à tout le monde. Moi-même, je ne suis pas super fort pour expliquer, mais j'essaie de faire l'effort de le faire. J'ai rencontré des dévs bien plus compétents, mais quand il y a un problème, ils le récupèrent pour le corriger sans rien expliquer, et au final je n'ai jamais peu comprendre ce qui n'allait pas, et donc impossible de corriger un cas similaire si je venais à retomber dessus.

Tout n'est pas qu'une histoire d'ego, c'est aussi des problèmes de relations humaines... Si on s'entend bien dans une équipe, on a plus de faciliter à respecter les règles sus-citées, alors que c'est s'il n'y a aucune communication, c'est beaucoup plus compliqué d'être attriste.
8  1 
Avatar de tontonnux
Membre expérimenté https://www.developpez.com
Le 06/01/2014 à 11:36
Citation Envoyé par SylvainPV Voir le message
Je plaide coupable pour ne pas respecter plusieurs de ces points. Par exemple, ça m'arrive de réécrire du code d'autres personnes sans les consulter. Mais c'est peut-être parce que certaines de ces personnes ont elles aussi leur égo et refusent d'admettre avoir tort. C'est d'autant plus difficile lorsque ces personnes ont dix ans de plus que moi... dur de se faire corriger par le petit jeune.

Je suis bien placé pour savoir que c'est assez mal vu lorsque quelqu'un ramène perpétuellement sa science. A l'école mes profs m'appelaient Monsieur je sais tout, parce que j'adorais les corriger lorsqu'ils se trompaient. Ponctuellement ça va, mais à la longue je passe au mieux pour un perfectionniste, au pire pour un emmerdeur prétentieux.

Alors est-ce qu'il ne vaut pas mieux parfois faire quelques modifs en douce, plutôt que de critiquer sans cesse (et même une critique constructive reste une critique). C'est le seul moyen que j'ai trouvé pour rester humble et apprécié sans laisser passer trop d'énormités dans le code.
C'est sûr qu'avec de tels propos, c'est facile de passer pour quelqu'un de prétentieux .

Cela dit, quelques soient les circonstances (que tu aies raison ou pas), faire une modification "en douce", donc sans consultation/validation est une énorme erreur dans un travail d'équipe ! Agir ainsi fait prendre le risque d'effets de bord non maîtrisés sur l'ensemble du projet. Si tu choisi de prendre seul ce genre de responsabilité, alors oui c'est de l'arrogance mal placée.

A partir du moment où 100% des développeurs va faire des erreurs, il est indispensable d'avoir des procédures et méthodes de travail rigoureuses qui DOIVENT être respectées par tous au sein d'une équipe !
Faut pas faire son Christiano Ronaldo sous prétexte qu'on dribble mieux que les autres.
7  0 
Avatar de r0d
Expert éminent https://www.developpez.com
Le 08/01/2014 à 16:02
Citation Envoyé par Hinault Romaric Voir le message
Quelles autres règles proposez-vous pour le développeur sans égo ?
11. Prenez le temps de jouer avec le logiciel que vous êtes en train de développer.

C'est le conseil que je donne aux stagiaires et débutants qui travaillent avec moi. Ça a l'air de rien comme ça, mais passer du temps dans la peau de l'utilisateur permet de:
- prendre un peu de recul sur la technique pure du code. Ça fait du bien de décrocher du code de temps en temps, ça aide à prendre du recul et à y voir plus clair.
- comprendre pourquoi une fonctionnalité est si importante pour les utilisateurs, alors que pour nous ça parait stupide.
- mieux connaître le produit sur lequel on travaille, ce qui aide beaucoup dans les discussions, même technique, avec les supérieurs, les collaborateurs et les clients.
- trouver des problèmes (bugs, erreur de conception, problèmes de performances, etc.) le plus tôt possible. Or plus un problème est identifié tôt, plus il est facile à résoudre.
- comprendre à quoi sert notre code. Ca peut paraître stupide, mais avec l'expérience, je me suis rendu compte que beaucoup de développeurs ne se préoccupent pas de savoir à quoi sert le code qu'ils écrivent. Connaître la finalité d'un algorithme aide grandement à améliorer toute la chaîne de dépendances.
7  0 
Avatar de pcdwarf
Membre éclairé https://www.developpez.com
Le 10/01/2014 à 11:22
Êtes-vous un développeur sans égo ?

Non et c'est tant mieux car quelle est la motivation à produire du code propre si se n'est la fierté ?
A choisir, je préfère travailler avec des gens un peu trop fiers de ce qu'ils font qu'avec des gens qui n'en ont rien à foutre.

Comprenez et acceptez que vous alliez faire des erreurs.

Oui évidemment tout le monde fait des erreurs. Cependant il y a des erreurs qui en disent très long sur la compréhension d'une technologie ou d'un problème et il est parfois difficile de ne pas se moquer.
Et quand on se rends compte qu'on en a fait une dans ce genre, il est plutôt bénéfique de se sentir honteux. C'est le meilleur moyen de s'améliorer.

Vous identifiez-vous dans ces commandements ?

Non.
Le commandement le plus intenable est le 8 : Il faut se battre pour ses idées, mais accepter gracieusement la défaite. Acceptez que, parfois, votre raisonnement ne soit pas suivi. Même si plus tard il s’avère juste, il ne sert à rien de remettre sur le tapis le « Je vous l’avais bien dit »."

Je regrette mais il y a un moment où « Je vous l’avais bien dit » est juste une soupape pour ne pas se jeter par la fenêtre ou plus précisément pour ne pas jeter quelqu'un par la fenêtre... Que l'on ne suive pas l'avis non-conventionnel d'un dev junior qui sort de l'école, ç'est un peu logique. Si il s'avère qu'il avait raison, il est important pour lui de le reconaite et de mieux l'écouter par la suite. Par contre, on ne peut pas balayer comme ça l'avis d'un developpeur qui commence à avoir un peu de bouteille et a fait les preuves de sa compétence. Il y a un moment où l'on ne devrait pas avoir besoin de se battre pour ses idées, pas a se battre pour les "vendre". Ce que je veux dire, c'est après une longue expérience positive, il y a un moment ou la confiance se mérite à priori et ne se remet en cause qu'après constat d'échec.

"Mon avis est qu'il faut s'y prendre de telle façon. Ayez confiance dans mon expertise, je peux me tromper mais j'ai la statistique pour moi. Si vous décidez contre mon avis, alors VOUS êtes responsable de cette décision et vous pouvez compter sur moi pour vous mettre devant vos responsabilités en cas de problème. Il est en tout cas hors de question que la responsabilité en retombe sur l'exécutant c'est à dire sur moi.

Concernant le point 5 : Traitez les gens qui savent moins que vous avec respect, déférence et patience.

Oui, mais je rappelle que le respect ne peut qu'être mutuel. Sinon, ça s'appelle de la soumission. On a évidemment le droit d'être ignorant. On a le droit de ne pas comprendre du premier coup, on a le droit d'être dans l'erreur, mais par contre, quand on est pas compétent, on ferme sa gueule. Ca signifie que lorsque un technicien dit fermement à un non-technicien qu'il se trompe, le non-technicien doit avoir l'humilité de la boucler ou de s'intéresser à apprendre. Ce qui me défrise ce sont ces non-techniciens qui croient tout savoir et que tout est simple. C'est vrai, aller sur la lune c'est trivial. Une grosse fusée, on allume ça pousse ça monte et après il suffit de bien viser, je vois pas où est la difficulté... Je prends sur moi une fois ou deux pour expliquer mais il y a un moment où je ne peux que mépriser ce type de personnes.
7  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 03/01/2014 à 22:32
Citation Envoyé par AlexRNL Voir le message
C'est peut-être toi qui a tort, non ?
Bien sûr, je me trompe comme tout le monde. J'irais même jusqu'à dire que j'aime me tromper, parce qu'apprendre d'autrui est un formidable rapport humain et parce que c'est une opportunité pour se corriger et se sentir grandi. Bienheureux les simples d'esprit disaient les saints hommes. J'admire aussi Descartes pour sa méthode basée sur le doute. Chacune de ses propres certitudes qu'il brisait était un obstacle de moins dans sa quête de vérité.

Et pourtant, je retrouve régulièrement dans mon travail au quotidien ce sentiment de conviction et de confiance en son propre jugement, face à une erreur de logique qui vient me titiller le cerveau. Peut-être est-ce la faute à mes profs et mes patrons qui me rabâchent aussi loin que je me souvienne que je fais de l'excellent travail. Ou peut-être que je suis juste un con arrogant. Quoi qu'il en soit, je prends un certain nombre d'initiatives et j'en assume les conséquences. Je préfère aider les visiteurs de developpez.net plutôt que les collègues qui ne me demandent rien.

@transgohan: jusqu'ici, mes patrons sont très contents de moi. Mais si un incident de ce genre venait à se produire, alors ce sera sans doute la leçon dont j'ai besoin, et je tâcherai de la recevoir avec humilité.
7  1 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 05/01/2014 à 10:04
En cas de pépin, critiquer le travail d'un développeur est plutôt facile, sur *tous* les projets auquel j'ai participé sans exception je trouve un tas de choses qui auraient pu être mieux faites différemment, si on avait eu plus de temps, si on avait pas rajouté 250 trucs pas prévus au départ dans le cahier des charges, si... bref. On est toujours plus malin après, c'est valable dans tous les métiers et tout particulièrement dans le nôtre.

Donc accepter qu'on vienne vous faire la morale sans tenir compte du contexte et des contraintes qui étaient en vigueur au moment où vous avez fait un travail, ne pas argumenter sous prétexte que vous devez être ouvert et accepter la critique, pour moi c'est le truc idéal pour servir à tout le monde de paillasson puis être le seul à finir avec sa tête empalée sur une pique. Moralité, ayez un égo, un égo mesuré mais un égo tout de même, les bonnes pattes elles finissent mal.
8  2 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 03/01/2014 à 21:08
"il ne sert à rien de remettre sur le tapis le « Je vous l’avais bien dit »"

Voila un principe que je n'approuve pas du tout. A un moment, il est quand même nécessaire de reconnaître qui avait proposé la bonne solution. Sinon, la prochaine fois, ça sera à nouveau exactement la même chose !

Ce point précis signifie en gros qu'il accepter les mauvaises solutions et les impasses et ne même pas chercher à en tirer les leçons pour une prochaine fois. Ca me parait plutôt étrange. On va dans le mur, je le sais, mais je dois l'accepter. Vous connaissez la signification du terme "death march" en informatique ?

https://en.wikipedia.org/wiki/Death_...ct_management)

Je veux dire : il y a des moments où il faut faire des choix et où je peux considérer qu'un autre choix que celui que j'aurais fait peut être valable. MAis il y a aussi des situations où on va à la catastrophe. Faut-il simplement l'accepter ?
9  4