Discussion :

[vb159753]

@Mr6:
Je connaissais pas, et effectivement, je retrouve ce principe dans ma boite, de mon point de vue (sans dire que les autres sont des incompétent)

[la.lune]

"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 !

Et vous vous voulez qu'ils disent : « Oui vous aviez raison, on excuse de n'avoir pas vraiment pris en considération votre proposition », mais qui vous a dis que prochainement vous aurez la bonne solution.

Ce que j'allais dire c'est qu'il ne faut pas dire: « Je vous l’avais bien dit » mais d'attendre le moment où on cherche à nouveaux ses solution et dire : « Prenons le temps d'analyser profondément toutes les alternatives avant de décider pour ne pas reculer après, comme on l'a déjà fait précédemment »

Là on se souviendra de vous vraiment sans que vous le disiez.

Car le terme "Je vous l’avais bien dit" c'est comme si vous pointez le doigt aux autres, et que c'est eux la cause de l’échec. Alors que les décisions qu'ils avaient pris ils croyaient qu'elles étaient les bonnes. S'ils savaient que ça allait échouer ils n'allaient les prendre.

[Zefling]

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.

[Sunchaser]

[*]La seule véritable autorité acceptable découle de la connaissance et non du pouvoir.

Wouhaaahou!!
Bien venu dans le monde des bisounours !
Seule une boite de pub a pu sortir une connerie pareille ...

Je suis suis pas un développeur sans égo, je suis un développeur sans égal

Excellent !
Bravo !
Je t'en félicite et n'en doute pas une seconde ...
(mince, il y aurait un concours de petites phrases, je voterais très certainement pour celle-ci)

Un être humain peut-il être sans aucun ego ?

Un être humain sain de corps et d'esprit ? Non.
Un "psychopathe", un déprimé en train de préparer son suicide, oui.

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

De changer de boulot, parce qu'il ne croit plus en ce qu'il fait.

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

Non, car je suis un être humain, avec ses points forts et ses faiblesses.
Tout ceux qui répondent "oui" soit se mentent à eux-mêmes, soit devraient consulter.

[psykokarl]

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.

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.

[vijvij]

Êtes-vous un développeur sans égo ?
Dur de se juger personnellement, c'est aux autres de la dire, mais je pense être plutôt de ce type

Vous identifiez-vous dans ces commandements ?
J'adhère à la grande majorité de ces points.

Quelles autres règles proposez-vous pour le développeur sans égo ?
Concernant le pouvoir, le point 7 est très bien vu, j'aurais un ajout concernant ce sujet:
Tu ne laissera pas les gens formellement en charge du pouvoir se défiler de leur responsabilité en pilotant systématiquement à vue et en laissant l'anarchie s'installer dans leur équipe...

[chaplin]

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


Le programmeur est souvent stéréotypé 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 passant 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.


Et vous ?

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

Vous identifiez-vous dans ces commandements ?

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

Pour un début d'année, c'est certainement le post le plus intéressant que j'ai vu. J'ai fait l'expérience dans une mission d'adopter le profil "sans égo". PLUS JAMAIS! Il est sûr que toute la partie sur laquelle j'ai travaillé a été vue et revue en long en large par tous mes collègues. Certainement la partie du code la plus claire, la plus propre de tout le programme.

A ceux qui veulent se prêter à ce jeu, je les préviens, vous êtes massacré et viré à la fin comme un tas de merde, car 90% des développeurs ne reconnaissent par leur tord, en revanche, ils ne se privent pas pour dégueuler sur votre compte.

Bravo pour ce fil de discussion!

[_skip]

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.

[LSMetag]

Wouhaaahou!!
Bien venu dans le monde des bisounours !
Seule une boite de pub a pu sortir une connerie pareille ...


Excellent !
Bravo !
Je t'en félicite et n'en doute pas une seconde ...
(mince, il y aurait un concours de petites phrases, je voterais très certainement pour celle-ci)


Un être humain sain de corps et d'esprit ? Non.
Un "psychopathe", un déprimé en train de préparer son suicide, oui.


De changer de boulot, parce qu'il ne croit plus en ce qu'il fait.


Non, car je suis un être humain, avec ses points forts et ses faiblesses.
Tout ceux qui répondent "oui" soit se mentent à eux-mêmes, soit devraient consulter.

Grâce à ton post, j'ai édité le miens. Oui je ne suis pas un développeur sans ego ^^. Si je n'avais pas d'ego, je ne chercherais pas à satisfaire l'utilisateur mais uniquement mon patron, qui n'est pas sur le terrain.
Je cherche une entreprise qui soit un minimum "bisounours" comme tu dis. Je me suis fait "virer" de ma dernière boîte car justement, je l'ouvrais trop (ce qui était une qualité dans celle d'avant mais où on s'est retrouvé en chômage technique (on avait trop bien bossé) ^^).

[wirenth]

Traduire (mal) un post de 2006 et en faire un article... On doute plus de rien à dvp.

[pcaboche]

D'un côté, on a les développeurs avec un égo sur-dimensionné, mais qui trouvent des solutions pour faire tourner la boite.

D'un autre côté, on a les développeurs sans réelles compétences et qui font tout pour s'attribuer les lauriers, comme décrit dans le lien suivant (je suis tombé dessus par hasard il y a quelques jours en cherchant complètement autre chose) :
http://www.daedtech.com/the-7-habits...errated-people

Mais le pire, c'est de forcer les deux à travailler ensemble, ça donne une réaction chimique assez détonante... (avant de retomber sur le principe de Dilbert)

[pcaboche]

D'ailleurs, un égo démesuré n'est pas l'apanage des développeurs. On retrouve cela aussi parmi les membres du management :
http://dilbert.com/strips/comic/2013-11-08/

[djibxav]

Le problème de la 8 c'est qu'elle vient souvent après la 7

Quand quelqu'un refuse systématiquement mes idées, uniquement pour asseoir son pouvoir hiérarchique, et non par le fruit de la réflexion, je ne me prive pas de lui remettre son abus de pouvoir dans les dents une fois prouvé que j'avais raison et qu'il s'est vautré.

Ces règles sont bien belles, mais fonctionnent surtout dans un monde idéal. Dans un monde du travail surchargé en egos démesurés, elles sont surtout bonnes à se faire marcher dessus si appliquées sans discernement.

Je suis sans ego face aux sans ego, ce n'est pas une raison pour appliquer ces règles aveuglement faces aux egos surdimensionnés.
Je ne tend pas toujours l'autre joue.

[Uranne-jimmy]

Certaines de ces règles sonnent comme un credo, c'est presque sectaire (ou biblique, ça dépend l'opinion qu'on a du sujet).
Franchement, je suis un geek asocial qui ne fait que rester assis à coder seul dans mon coin (en même temps, que faire d'autre quand on est le seul info de l'entreprise ...) mais je n'ai pas cet ego qui semble faire partie de l'archétype, au contraire, tout codeur passe pas mal de temps à débogger, on code, on observe le résultat et à tout les coups on a des modifications à faire. Dans une discipline aussi peu souple prendre les erreurs pour soit c'est suicidaire ^^

Après cette charte est sympa et montre assez bien l'esprit d'un forum tel que developpez, il faut mettre l'ego de côté et avancer à plusieurs afin d'obtenir le meilleur résultat et à ce moment seulement en être fier et le protéger des critiques (sauf celles qui sont constructives). Et étant un bon gros noob, ce "code d'honneur", m'arrange bien

[Golgotha]

Le programmeur est souvent stéréotypé 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é.


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

Source : Coding Horror


Et vous ?

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

Vous identifiez-vous dans ces commandements ?

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

qui reste assise à longueur de journée devant un écran

Je me voie mal faire du développement allongé ou debout...

Sans ego ? Pour moi, gros problème puis-qu’à mon sens personne ne peut être "sans ego", on peux avoir un gros ego, un petit ego, mais pas d'ego c'est impossible, l'ego c'est nous, c'est le "je".

Tout ces "commandements" (pourquoi appeler cela des "commandements", n'y à t'il pas de mots plus laid..) sont ni plus ni moins que des préceptes philosophiques que tout le monde devrait suivre, dans tout les domaines, j’espère qu'on aura pas attendu le développement pour suivre des leçons aussi élémentaire..

Par ailleurs, sur le fonds je ne suis pas d'accord avec l'article ni l'auteur original, le développeur est un artisan qui créer quelques chose en partant d'un page vierge, c'est normal qu'il soit touché quand ont critique sont oeuvre, sa création. Tel un menuisier qui à passé des jours à soigner chaque recoins minuscule d'une chaise ou d'un meuble.

On cherche à faire du développeur un ouvrier à l'usine ? ça sera sans moi.

[Uranne-jimmy]

J'ai l'impression que tu as pris l'article dans le mauvais sens. Il prône des valeurs que tout le monde devrait appliquer et également le partage des connaissances et des capacités, tout artisan, comme tu le dis si bien, n'a pas vocation à faire l'ouvrier d'usine, au contraire, étant donner que dans bien des cas, nous sommes les créateurs d'un outil qui remplace l'homme sur les tâches abrutissantes et répétitives.
Après je suis d'accord, on fait un raccourci en indiquant ne pas avoir d'ego. En fait pour être juste il faudrait dire qu'on ne permet pas à notre ego de s'exprimer et on ravale sa fierté dans le but de s'améliorer et de pouvoir être fier de ces améliorations. Mais là encore c'est de la simple philosophie de comptoir qui radote sur des faits déjà acquis :p

[tontonnux]

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.

[Golgotha]

Sans critique, on ne peux pas s'améliorer.

Je préfère être critiqué et m'améliorer sans cesse, que de rester un imbécile heureux.

[chaplin]

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.

Tu as tout à fait raison. Plutôt que de parler de développeur sans égo, on pourrait étendre la réflexion à stratégie du "sans égo". C'est un mode opératoire qui peut fonctionner à condition de ne pas avoir un individu à l'égo surdimensionné dans l'équipe.

La leçon dont j'ai tiré de cette expérience est que la stratégie à magnifiquement bien marché par rapport à la réussite du projet, mais d'un point de vu financier, on me l'a fait payer et du coup l'égo revient au galop.

On peut avoir les meilleurs codeurs du monde, si on a rien compris au métier, le programme part à la poubelle. Aux chefs de projets, ne jugez pas uniquement les codeurs à leur compétence purement technique, mais également à leur capacité à comprendre le métier. Un proverbe chinois dit qu'il vaut mieux marcher dans la bonne direction que courir dans la mauvaise.

[LSMetag]

D'un côté, on a les développeurs avec un égo sur-dimensionné, mais qui trouvent des solutions pour faire tourner la boite.

D'un autre côté, on a les développeurs sans réelles compétences et qui font tout pour s'attribuer les lauriers, comme décrit dans le lien suivant (je suis tombé dessus par hasard il y a quelques jours en cherchant complètement autre chose) :
http://www.daedtech.com/the-7-habits...errated-people

Mais le pire, c'est de forcer les deux à travailler ensemble, ça donne une réaction chimique assez détonante... (avant de retomber sur le principe de Dilbert)

Héhé, j'ai expérimenté ^^. Moi le développeur avec ego, en équipe avec une développeuse débutante sans ego très caractérielle => BOOOM !!!!