Discussion :

[pcaboche]

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

Pire...

D'un côté : développeur junior qui essaye d'optimiser tant bien que mal les ressources du serveur pour mieux supporter la charge.

De l'autre côté : développeuse dite "senior" avec certification ITIL et tout le bazar, mais bonne uniquement à essayer de se faire bien voir auprès de la direction, à envoyer des e-mails du genre "j'ai fait ceci", "j'ai fait cela"... (bref, la plupart des points évoqué dans le lien que j'ai cité précédemment) sauf que chaque modif entraînait une dégringolade des performances durement gagnées.

À ce niveau, c'était plus une réaction explosive par-ci par-là, c'était carrément (des deux côtés) : bombes à fragmentation, mines anti-personnel et incendies à coup de Napalm...

[DonQuiche]

La connaissance engendre l’autorité, et l’autorité suscite le respect. Si vous voulez du respect, cultivez le savoir.

Et si vous voulez une promotion, jouez plutôt au golf ou au tennis.

Les personnes non techniques qui traitent avec les développeurs régulièrement trouvent ceux-ci pleurnichards

Règle de DonQuiche : les utilisateurs les plus stupides, feignants et casse-bonbons sont ceux qui cherchent le plus souvent à contacter le support technique et les développeurs.

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.

Et bien justement ça apporte de la valeur ajoutée et c'est de ça dont il faut les convaincre. Si ton encadrement a l'impression que ça n'est pas le cas, il est normal qu'ils refusent. Parle leur langage et propose-leur une évaluation du coût et de la valeur générée.

[madislak]

J'en ai que 6 sur 10 :
- Je suis assez susceptible quand on me fait remarquer que j'ai laissé des bugs à la con
- J'aime pas trop changer mes habitudes et mes outils
- Je suis un grand spécialiste du "je vous l'avais dit que ça planterait" ^^
- Je critique jamais le code d'un autre, mais j'aime bien chambrer gentiment sur les standards et les bonnes pratiques

C'est cool ce genre d'article, ça remet les développeurs à leur place quand ils commencent à se prendre un peu trop pour les rois du monde (oui, moi aussi j'en ai besoin de temps en temps ^^)

[psykokarl]

Et bien justement ça apporte de la valeur ajoutée et c'est de ça dont il faut les convaincre. Si ton encadrement a l'impression que ça n'est pas le cas, il est normal qu'ils refusent. Parle leur langage et propose-leur une évaluation du coût et de la valeur générée.

Les tests unitaires apportent de la valeur ajouté aux process et non au produit fini. Il est tout simplement plus facile de convaincre le béotien de la valeur ajouté le de nouvelle petite icône qui change de couleur quand on passe la souri dessus que du script qui ne laisse pas passer les erreurs prévisibles (et donc que l'on ne devrait pas faire...).
Quelque part le développeur sans ego, parce qu'il délivre plus vite et est passé expert dans l'art de cacher la misère, sera plus apprécié. C'est humain comme constat finalement...

[Invité]

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

extrait du lien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Here’s what I mean. Let’s say that you’re working with Bill and Bill goes home every night at 6:00 PM.
At 6:01, send Bill an email saying that you’re all set to get to work, but you just need the class stub from
him to get started. Sucker.
Now 15 hours are going to pass where he’s the bottleneck before he gets in at 9:00 the next morning
and responds.
If you’re lucky and you’ve buried him in digest emails, you might even get an extra hour or two.

Je reste dubitatif, le dev qui part à 6 heures a surement fait son boulot ( sinon virez le ), alors pourquoi lui demander d'en faire 2 de plus car son collègue ne sait pas s'organiser ( maladie qui se soigne, envisager une thérapie collective ) ?
Mais je n'ai peut-être pas compris...

À ce niveau, c'était plus une réaction explosive par-ci par-là, c'était carrément (des deux côtés) : bombes à fragmentation, mines anti-personnel et incendies à coup de Napalm...

Je ne doit pas avoir d'égo ou alors c'est la violence de la société ( 4 morts le jour de l'an ) mais je n'ai pas du tout envie de me battre contre un collègue.
Je préfère dépenser mon énergie pour des choses plus intéressantes.

[Invité]

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

Je suis d'accord avec vous, mais pour y avoir été confronté ( et pas tout seul, les autres dev aussi ) contre mon ancien patron, j'aimerais bien savoir par quelle magie on peut arriver à changer les choses ?

[Uranne-jimmy]

je n'ai pas du tout envie de me battre contre un collègue.
Je préfère dépenser mon énergie pour des choses plus intéressantes.

Des paroles pleines de sens ! On a tous de l'égo, mais on a aussi tous un raisonnement (j'espère), et il y a des priorités dans la vie !

Pour ce qui est de l'extrait : demander a quelqu'un de fournir des documents au moment où il n'est pas là est en effet un moyen efficace d'avoir une raison de ne rien faire. Après si le flemmard est là à 18h, c'est sans doute parce qu'il a pas le choix et si il se fait pas virer c'est qu'il joue finement ^^

[pcaboche]

extrait du lien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Here’s what I mean. Let’s say that you’re working with Bill and Bill goes home every night at 6:00 PM.
At 6:01, send Bill an email saying that you’re all set to get to work, but you just need the class stub from
him to get started. Sucker.
Now 15 hours are going to pass where he’s the bottleneck before he gets in at 9:00 the next morning
and responds.
If you’re lucky and you’ve buried him in digest emails, you might even get an extra hour or two.

Je reste dubitatif, le dev qui part à 6 heures a surement fait son boulot ( sinon virez le ), alors pourquoi lui demander d'en faire 2 de plus car son collègue ne sait pas s'organiser ( maladie qui se soigne, envisager une thérapie collective ) ?
Mais je n'ai peut-être pas compris...

C'est justement ça le principe...

En fait, développeur 1 n'a pas du tout envie de bosser. Alors pour arriver à ses fins, qu'il fait c'est :
- attendre patiemment que développeur 2 rentre chez lui
- envoyer un e-mail quelques minutes plus tard pour incriminer développeur 2 (de manière fallacieuse)
- rentrer chez lui

D'où le nom : "Time It So You Look Good (Or Everyone Else Looks Bad)"

je n'ai pas du tout envie de me battre contre un collègue.
Je préfère dépenser mon énergie pour des choses plus intéressantes.

Oui, je suis d'accord (en règle générale).

Le problème, c'est quand t'as un(e) collègue qui te discrédite à longueur de journée parce que tu as le malheur de te trouver entre lui (/elle) collègue et une jolie promotion.

Si ce(tte) collègue applique les techniques enseignées dans le lien que j'ai cité (en particulier : 1, 2, 4, et 7), et que par dessus le marché le soi-disant "chef" laisse faire sans réagir, c'est que la situation est sans issue...
Or quand une situation est sans issue, par définition, c'est qu'on n'a plus rien à perdre (pire : tu vois bien que si tu ne fais rien, ça risque de te retomber dessus).

Dans pareille situation, on ne te laisse pas d'autre choix que de jouer ton va-tout (en l'occurence : "t'as décidé de me faire plonger ? Très bien. Maintenant je te préviens : si je plonge, tu plonges avec moi... ") et pas question de se rendre sans combattre.

[al1_24]

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

En lisant ceci, j'ai immédiatement pensé à cela :

Il existe deux grandes règles pour conserver le pouvoir par la connaissance :
La première, c'est de ne pas partager tout son savoir...

[r0d]

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.

[lebaba]

Oui, je suis un développeur avec ego. Je pense que ce n'est pas un mal,il ne faut juste pas s'enfermer dans son ego et refuser la vérité.
J'accepte les critiques quand l'autre ne me prend pas de haut (car je ne le fais pas). Je déteste qu'on touche à mon code, qu'on me prévienne s'il faut des modifs.
Mais oui je suis d'accord avec tous ces commandements. En même temps, le mythe du programmeur/concepteur asocial, refusant les critiques c'est une espèce en voie de disparition. On a plutôt des "copieurs/colleurs", mais ça c'est un autre sujet...

[wangu]

Pour le point 4, ce serait bien de traduire "fixing code" par "corriger le code" (ou "correction du code") et non "code de fixation".
La phrase ne veut rien dire avec la traduction actuelle.

[Franck.H]

Suis quelqu'un de très ouvert, j'accepte les critiques si cela permet d'améliorer le code et les performances du programme. Si je critique le code de quelqu'un d'autre c'est aussi souvent parce que le code est horrible, ne suis aucune convention et n'est pas un minimum optimisé sinon je la ferme

J'accepte de mes supérieurs leurs remarques sur mes codes et eux également, acceptent mes idées pour leurs programmes. C'est un échange qu'il ne faut pas hésiter à faire car "la connaissance ne sert à rien si elle ne peut être partagée"

"Accepter les critiques c'est progresser"

[YoyoS]

Pour ma part je pense que les cadres ont aussi un rôle social à jouer dans la bonne communication et entente d'une équipe de développeurs.

Même en considérant ou non le principe de Dilbert, le cadre n'a pas à être aussi compétent dans le domaine d'un subordonné. Je le verrais plus doué dans la supervision globale inter équipe, une personne qui donne une ligne directrice à suivre de façon rectiligne ou sinusoïdale en fonction des caractères de chacun.

Personnellement, je réfléchis beaucoup (trop ?) avant de me lancer dans un projet. On peut à la fois me le reprocher ou m'en faire éloge. Les avis sont tranchés. A l'inverse, d'autres s'attaquent plus vite au code et jouent un peu le kit ou double quant au futur. Ils passent pour de bons dev puisqu'ils "terminent" un projet assez vite mais c'est moins amusant quand il faut repasser ensuite dessus. Le tout est de pouvoir discuter et prendre des décisions aussi entre développeurs et que le cadre ait assez d'expérience pour choisir les bonnes décisions. Laisser totale liberté à des développeurs égocentriques qui doivent travailler ensemble ne mènera jamais à quelque chose de bon.

Les commentaires sont plus intéressants que l'article en tout cas

[pcdwarf]

Ê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.

[Ah_Kin]

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.

Ceux qui rigolent ce sont les développeurs qui se jouent de ceux qui apprennent et qui n'acceptent pas que leur code n'est pas parfait et comprend des erreurs.

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.
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.
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.

Autoentrepreneur depuis 2 ans en dépannage / développement, je côtoie régulièrement les gens de la bibliothèque où je travaille mon code pour les clients. Mes tarifs sont les plus bas afin de lutter contre la concurrence des "grands". J'ai 2 collègues dont un photographe et un infographiste avec qui on se sert les coudes. Si personne ne m'embauche, c'est parce que les gens qui embauchent n'embauchent que les grosses pointures qui profitent de la moindre occasion pour rabaisser son prochain en critiquant son code et en s'en gaussant avec ses potes. Ils vont jusqu'à critiquer la manière de parler du développeur qu'ils ne connaissent pas et, sachant que leur potes ne le connaîtront surement pas vu qu'ils se connaissent tous et qu'ils sont tellement sociables, ils écrasent ses propos à l'unisson jusqu'à ... pas grand chose, ils ne cherchent qu'à s'amuser.

L'autre jour, dans votre chatroom, j'ai copié coller le code jquery d'un gars qui venait aider et n'ai changé que la place du code, c'est à dire que j'ai mis le script jquery juste avant </body> et ai isolé le jquery en le mettant dans une fonction anonyme. Le gars venu demander de l'aide n'a pas demandé à ce que ce qu'il cherchait soit changé, mais le gars qui était là pour aider l'a fait, et en fait son code était très correct et judicieux, à part ce problème de mettre le jquery dans le head de la fonction que j'ai préféré mettre à la fin.

Et j'ai eu droit à ton code est monstrueux, apprend à faire du javascript, il a fallu que je calme le jeu avant de m'énerver à mon tour en commençant par du "et toi le jquery" qu'il a justifié par du c'est juste une question d'esthétique. Pour moi c'est un défaut de pédagogue. On n'est plus en primaire, les ingé. Si vous enseignez mal par ici, c'est normal que les gens apprennent mal. Écrasez les petits comme moi mais prière de commencer vos phrases par MOI je ferais comme ça. Il y a la bonne méthode, il y a la mauvaise méthode, et il y a ta méthode, qui n'est pas forcément bonne.

Si ces gars ont la dent dure, qu'ils restent enfermés chez eux, ça vaut mieux, vu que les recruteurs ou autres prophètes n'ont que ces expressions à la bouche. Je les leur retourne violemment dans la face. C'est une fausse vérité qui cache de la pure discrimination.

C'est un peu comme si on disait qu'aujourd'hui, on est en démocratie.

PS. C'est normal que ces gens là, qui aident en écrasant leur prochain, aient un profile vierge?

[TIFéç]

+1 avec pcdwarf

Êtes-vous un développeur sans égo ? Non et c'est tant mieux

Par ailleurs, je suivrai le N°8 en faisant preuve de bien plus de bonne volonté si seulement le N°7 était vrai! Le problème est bien souvent que le pouvoir de décision est donné à des gens rarement compétents techniquement (chefs de projet, resp. fonctionnel, voir pire au client...) et que les bons conseils de "l'expert" sont finalement rarement retenus car souvent uniquement perçus en termes de coûts.

Et cela m'amène à nuancer le N°5 : j'aide toujours avec beaucoup de plaisir ceux qui en savent moins et qui cherchent à comprendre, je suis en revanche beaucoup moins patient avec ceux qui en savent moins et qui pourtant ne tiennent pas compte de mes suggestions (à commencer par un petit chef qui a snobé mes conseils et qui revient me voir pour m'expliquer que la situation est maintenant hors de contrôle et qu'il va falloir que je fasse un maximum d'heures pendant plusieurs jours/semaines pour corriger les comportements sur lesquels je l'avais alerté).

Sur le N°9, "Ne pas être « le gars dans la chambre »", il me semble qu'il y a 2 aspects à différencier : être coupé de ses collègues est évidemment à proscrire, mais être "hors de contact" du donneur d'ordre est malheureusement bien souvent "organisé" et donc subi. L'organisation de projet type SSII implique bien souvent tout un tas de réunions pour que les responsables fonctionnels et de projet coté client et fournisseur échangent, mais les développeurs sont rarement invités (trop cher, problème de délais,... => faut qu'ils codent!)

Quant au n°10, encore faudrait t'il que la personne en question produise du code, cela devient de moins en moins fréquent même en SSII...

Quelles autres règles proposez-vous pour le développeur sans égo ? Franchement, est ce vraiment un objectif?

[ddoumeche]

Sinon juste une petite remarque, "être dans la chambre" je suppose que c'est un idiomatisme américain c'est mal traduit

Je pense que le terme "être dans un tunnel" correspond bien.

[CodeurPlusPlus]

pcdwarf a tout dit ! Je pense que la discussion peut être considérée comme "résolue".

(ok je sors)

[bizulk]

D'accord sur la plupart des points, qui sont plutôt sur les comportements inter-développeurs. Mais ils sont loin d'être les plus problématiques.

Concernant les comportements les personnes occupant d'autres postes :

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.

--> il y a deux lignes de conduite décorrélées là.
Sincèrement si on se plaint c'est justement parce que l'on nous écoute pas. Trop souvent j'entends du "oui mais tu pas tout d'autres choses entre jeux", ainsi de suite. Il ne faut pas oublier que l'on est en première ligne sur l'ouvrage à réaliser. Et oui Je me plains quand le client me demande une modif, me dit comment le faire mais sans préciser son besoin, et s'exciter quand je joue le jeu en demandant des précisions et que cela nous coute des jours de boulot à l'oeil. Désolé de constater que le CDP ne réagit pas et patiente jusqu'à ce que ça passe, et ensuite me prend pour un "pleurnichard".

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 ».

Pourquoi vient-on nous demander notre avis quand on sait d'office qu'il n'est pas prioritaire ? Si on ne rappelle pas que l'on avait vu les choses autrement, on peut l'oublier et nous tenir responsable des erreurs.
Bon mais ça j'évite de le faire je trouve cela trop désagréable.

Bon d'accord il faut mettre son amour propre de côté parfois, mais une qualité d'un CDP est de savoir écouter son équipe et prendre les devant pour prévenir les risques.
De notre côté il faudrait réagir en changeant la forme, avec un message plus positif / adulte, car ces réactions ont fond légitime malgré tout.