Discussion :

[JPLAROCHE]

bonjour,

pour moi je me reconnais ...

mais je dirais que c'est le travaille qui commande et qui fait passez bien des fois notre ego de coté . même quand c'est pénible de ce trouvé devant un ignare ....

un truc par exemple qui est pénible a été d'être confronté à un barbu (arch) ou mon orthographe était plus important que la question posée alors que j'attendais une réponse claire j'ai eu le droit a une verve d'un prof de français exacerbé et d'un mépris bref .... même me poursuivant dans d'autre discutions auquel un autre avait gentiment répondu ce qui ma aidé .... et l'autre ce planter dans sa réponse (je n'ai même pas relevé ni lui est mis le nez sur son ignorance)

ALORS L'EGO SI VOUS NE LE JETER PAS DE COTÉ ......

il ne vous seras pas possible de pratiquer votre métier car pour comprendre vraiment les besoins il vous faut écouter et écouter c'est faire abstraction de ce que vous voulez entendre mais bien entendre ce qui vous est dit par votre interlocuteur afin de bien comprendre ce qu'il veut et c'est seulement après que vous ferez intervenir votre connaissance pour répondre si vous pouvez réaliser etc....

après plus de 40ans d'informatique je dis que c'est un merveilleux métier qui permet tel un art de grandir et jamais je ne suis allé au travaille a reculons à cause de l'informatique au contraire.

[sekaijin]

Salut
Discussion amusante qui dévoile nos personnalités. Pourtant, je la trouve basée sur un constat totalement faux. après une longue carrière, je n'ai jamais rencontré une boite dans laquelle :

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

Être tombé sur des personnages : OUI. Mais pas spécialement chez les développeurs.
Des asociaux : OUI. Et là encore, pas que chez les développeurs.
Des personnes qui n'acceptent pas la critique : OUI. Et cette fois beaucoup plus souvent dans d'autres postes que les développeurs.

Bref pour moi le développeur qui est un marginal asocial imbu de lui-même est un mythe qui n'existe que chez les développeurs.

Qu'il y ait de l'incompréhension interprofessionnelle là oui. Tout comme j'en constate entre les comptables et les médecins, les infirmiers et le personnel administratif de l'hôpital. Bref l'informaticien comme tout autre professionnel à son jargon, son mode de pensée (pas uniforme) qui est difficilement perçu par les autres. Mais rien de pire que pour les autres professions.

Quant à moi depuis mon enfance "plus j'apprends, plus je découvre l'étendue de mon ignorance."
J'ai quasi durant toute ma carrière été considéré comme un puits de savoir sans fond. Et pourtant je constate souvent que je suis celui qui est le plus prompt à dire «je ne sais pas». Je suis toujours preneur d'un regard extérieur sur mon travail. Je pense que plus de personnes se penchent sur un sujet, plus nous avons de perspectives, mieux nous le maitrisons. Je suis toujours prêt à apprendre.

Et pour moi, les règles qui sont citées ici sont au contraire de règles qui renforcent l'égo. Elles remettent la personne en tant que telle, et non plus en tant que profession, au centre, elle détache l'objet de l'individu, elles permettent à la personne de s'enrichir. Elles le rendent plus fort plus sur.

A+JYT

[CodeurPlusPlus]

(...)
Bref pour moi le développeur qui est un marginal asocial imbu de lui-même est un mythe qui n'existe que chez les développeurs.(...)

Je suis un marginal asocial imbu de moi-même. En fait j'ai un ego tellement démesuré que je n'ai jamais pu avoir de relation intelligente avec mes chefs. D'où dans un premier temps une vie professionnelle très bordélique (période pendant laquelle je n'ai jamais réussi à rester longtemps au même endroit)

Et puis un jour j'ai décidé de bosser tout seul dans mon coin. Maintenant que le chef c'est moi, y'a plus de problème !

[danielhagnoul]

Je suis un marginal asocial imbu de moi-même. En fait j'ai un ego tellement démesuré que je n'ai jamais pu avoir de relation intelligente avec mes chefs. D'où dans un premier temps une vie professionnelle très bordélique (période pendant laquelle je n'ai jamais réussi à rester longtemps au même endroit)

Et puis un jour j'ai décidé de bosser tout seul dans mon coin. Maintenant que le chef c'est moi, y'a plus de problème !

Les différends entre le "moi" développeur et le "moi" chef de projet sont certes discutés dans un cercle très restreint, mais il doit bien y avoir des cas où le "moi" développeur n'est pas satisfait du boulot alors que le "moi" chef de projet répète qu'il n'y a rien à gagner à peaufiner ce bout de code.

[sekaijin]

Je suis un marginal asocial imbu de moi-même. En fait j'ai un ego tellement démesuré que je n'ai jamais pu avoir de relation intelligente avec mes chefs...

Attention je n'ai pas dit que ce genre d'individu n'existe pas. Ni qu'il n'existe pas chez les développeurs.

J'ai dit que l'assertion qui sert de base à cette discu est un Mythe.
et cette assertion est que les non informaticien perçoivent souvent les développeurs comme...
ceci est pour moi totalement faux. le métier de développeurs est perçu par le commun des mortel et par les entreprises comme un autre.

Ce que je dis c'est que OUI nous avons tous rencontré de tel individus (pas toujours des développeurs) mais non ce n'est pas ainsi que nous sommes perçu.

Cette idée que le monde voit le développeur comme un Nurb, un Geek, un No life. est plus présente chez les développeurs eux même que chez les autres.

Il y a un dommaine ou on le représente ainsi ce sont les films et serie américaines.
Mais dans ce milieux on nous présene des caricatures de flics, des caricatures d'avocats, des caricatures d'analystes, des caricatures de ponpiers, ... et donc des caricatures d'informaticiens.

Je ne pense pas que dans la population française un soldat soit souvent vu comme "GI JO".

A+JYT

[damedom41]

Je travaille seule comme développeur de logiciel, et je REVE de pouvoir faire passer mon code à la 'moulinette' d'autres personnes, mais j'aimerais aussi faire bénéficier des moins expérimentés que moi (VBA Access only) d'une biliothèque de fonctions maintenant plutôt conséquente.

[TiranusKBX]

Êtes-vous un développeur sans ego ?
Oui à part pour je vous l'avais bien dit mais je me mesure ^^
Vous identifiez-vous dans ces commandements ?
Oui
Quelles autres règles proposez-vous pour le développeur sans ego ?
Trouver des commerciaux qui non pas d’ego démesuré et qui imposent des fonctionalités débiles voir infaisables aide à ne pas péter les plombs

[iciyas]

A part les programmes du débutant, qui pensez vous pouvoir laisser les autres tripoter son programme. pire piquer l'idée coeur de son programme.!
sauf si je me trompe.

[sekaijin]

???
il ne s'agit pas d’espionnage mais de partage entre collègues.

ici tout relecture par un collègue est bien venue.
nous n'avons pas de revue de code systématique mais lorsqu'un collègue le demande nous sommes tous près à le faire.
cela fait partit des bonne pratique. en général un développeur demande toujours une revue avant la première release.

les stats sur la qualité de notre usine logicielle nous incitent à le faire.
pour le vieux routard qui sont généralement toujours dans le vers. la tendance est de faire beaucoup de relecture partielle (sur des points précis)

généralement tout le monde en sort contant. je crois qu'il nous est tous arrivé de refaire une partie de notre dev. notre code est gros i y a beaucoup de chose déjà disponible et il arrive encore même à ceux qui sont sur le projet depuis longtemps d'écrire quelque chose sans utiliser l'existant.

Le dev c'est ce que tu vends à ton client le code c'est ce que tu laisse à tes successeurs.
et si les trucs fait pour durer disparaissent parfois très vite. le dev jeta prévu pour dépanner un temps reste souvent bien longtemps.
Alors le code ne sera plus que le seul moyen de maintenir la chose. plus il est partagé plus il est compréhensible plus il y a des chance que dans quelque année celui qui devra faire avec pourra s'en sortir.

A+JYT

[Invité]

Je suis un marginal asocial imbu de moi-même.

Développeur sans égaux ?



Steph

[TIFéç]

Bonjour,

A la lecture des nouvelles réponses, je vois deux questions /commandements qui pourrait être ajoutées à la bible du développeur sans égo, et qui en feront peut être réfléchir certains qui croyaient l'être...

pensez vous pouvoir laisser les autres tripoter son (votre) programme. pire piquer l'idée coeur de son programme

Effectivement, la notion de développeur sans égo pourrait intégrer la notion de propriété du code produit... Alors que je ne me reconnait absolument pas "sans égo", je considère en revanche mon code comme une forme de propriété commune (attention, il appartient légalement à mon employeur...). Ce code n'a souvent d’Intérêt réel que pour la société pour qui il est produit car trop/très spécifique (pa ex ihm j2ee), et est souvent une "adaptation" de ce que j'ai pu rencontrer par mon expérience, sur internet ou sur des forums comme celui-ci... Le "développeur sans égo" ne devrait il pas, par principe, renoncer à toute propriété / paternité sur le code produit?

stats sur la qualité de notre usine logicielle

La notion "d'usine logicielle" m'interpelle ici... Le développeur est lié à l'environnement technique qui est mis à sa disposition, la qualité de ses productions est forcément "moyennée" par les autres intervenants du projet (voir des entreprises précédentes....). Certains professionnels travaillent dans de bien meilleures conditions de qualité que d'autres, par exemple, pour ceux à qui ça parle, une plateforme de contrôle, voir d'intégration, continu permet aux intervenants de progresser tout en maintenant une qualité de code très élevée. Le "développeur sans égo" doit-il renoncer à ceraines exigences de qualité et accepter des environnements de travail mal maitrisés (ex: bcp de technos récentes dont les portails web souvent propriétaires), incomplets (pas d'outils sur certains aspects clé manipulés à "l'ancienne", comprendre au bloc note / emacs), peu reproductibles (1,2 voir 3 jours pour installer un environnement de dev) et / ou peu performants (gros temps de latence car environnement très gourmand en ressources)?

Si pour le coup je suis très ouvert à la discussion sur la première question, je suis en revanche beaucoup plus exigent sur la seconde, estimant qu'il s'agit de mon propre apprentissage et qu'au delà des problématiques de projet, il y a un réel enjeu quant à mes compétences et donc mon "employabilité" dans le métier (ce que mon employeur devrait "théoriquement" partager...).

[apad]

Je vais tenter d'argumenter point par point.

1) Pour Atwood, les erreurs sont rarement mortelles dans l’industrie du développement.
Atwood devrait s'intéresser aux métiers du contrôle aérien, de la chirurgie ou de la défense, il changerait sans doute d'avis.

2) Vous n’êtes pas votre code.
Ça fait très Fight Club : Vous n'êtes pas votre travail, vous n'êtes pas votre compte en banque ...

3) Peu importe le nombre de « karatés » que vous maitrisez, quelqu’un d’autre en saura toujours plus que vous.
Je confirme, en groupe, il y en a un qui a toujours tout vu, tout fait ....

4) Ne pas réécrire le code de quelqu’un sans le consulter.
Ca se discute surtout si le développeur s'est barré sans préavis et qu'il a laisser une grosse bouse dans le code.

5) Traitez les gens qui savent moins que vous avec respect, déférence et patience.
Patience, patience. Il connait pas mes utilisateur le Atwood !

6) La seule constante dans le monde est le changement. Soyez ouvert et acceptez cela avec un sourire.
Le changement c'est marrant une fois, deux fois. Mais quand il faut se remettre en question tout les 5 ans (espérance de vie d'une techno), ça devient ennuyeux.

7) La seule véritable autorité acceptable découle de la connaissance et non du pouvoir.
Accepter l'autorité, même de la connaissance c'est déjà renoncer à sa liberté.

8) Il faut se battre pour ses idées, mais accepter gracieusement la défaite.
Accepter de capituler devant les "je sais tout" (voir point 3), jamais !

9) Ne pas être « le gars dans la chambre.
Ça fait quand même du bien de se retrouver en tête à tête avec la machine. Les humains sont parfois plus binaires que les machines.

10) Critiquer le code plutôt que la personne.
Oui bonne idée, surtout si la quiche qui a pondu le code pourri mesure 2 mètres et fait 110 kilos.

[riete]

Mon mode de fonctionnement est basée sur l'auto critique, alors difficile de dire si je suis sans ego ou non.

A un instant je dirais oui je le suis et un peu plus tard ou plus tôt non je ne le suis pas. Cette question ne s'applique pas que pour le développeur que nous sommes mais bien pour l'être humain lui même dans tous ce pour quoi il est impliqué. j'irai même jusqu'à dire que cela à une dimension spirituelle car nous devons avoir une démarche d'amélioration permanente aussi bien professionnellement que humainement. Les deux sont souvent liés d'ailleurs.

J'aime beaucoup les commentaires qui sont fait sur ce fil et le fil lui même.

Tiens! posons nous quelques questions:

• Combien parmi tous le visiteur on client sur le titre "êtes vous une développeur sans ego?"
• Conbien se sont vraiment posé la question?
• Parmi ceux qui se la posent, combien sont honnêtes avec eux même?
• etc ...

Ma conclusion est qu'il est déjà extrêmement positif de se poser la question et de s'intéresser au sujet. Cela démontre déjà une ouverture d'esprit.

Alors suis je sans ego? sûrement pas car si je l'étais, je ne crois pas car il est illusoire de croire que l'on peut l'être. Cela démontre déjà que notre ego est trop important.

[e-ric]

Salut

Beaucoup de blabla pour simplement parler de savoir-vivre.

Arrêtrons de nous auto-flageller !! Par expérience, il n'y a pas que les développeurs qui devraient sans ego, pour reprendre le concept, les commerciaux de SSII, les chefs de projets, les utilisateurs aussi parfois devraient vivre "sans égo". Toutes les professions sont concernées.

Pour répondre aux commandements :

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.
>>Rien de spécifique aux développeur

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 comme la découverte est présentée.

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.
>>Rien de spécifique aux développeur

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.
>> Et le turn over???

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.
>> Elle est bien bonne, les développeurs sont des drôles d'individus...

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.
>> Les utilisateurs et les chefs sont souvent plus retords au changement que les dév.

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.
>> Encore un qui ne connaît pas les dures lois du monde du travail. Pipeau...

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

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.
>> On vit dans un monde merveilleux !

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.
>> Des fois, il vaut mieux même pas commenter tellement ça vole bas.

Désolé pour le cynisme, mais ces commandements semblent émaner d'une boîte de conseil en mal d'imagination et un peu déconnectée de la réalité ou qui prend les gens pour des cons. Il faut parfois revenir sur Terre.

@+

[Miistik]

N'ayant pas la même expérience que vous dans le code car non développeur de métier, je me pose une question.

La notion d'égo n'est-elle pas liée à une connaissance avancée ?

Je m'explique.

Pour avoir de l'égo, il faut une "maîtrise" du code ou un bagage de développement étayé.

Pour ma part, ayant des bases de programmation, je suis un développeur sans égo car je ne dispose pas de la connaissance approfondie que vous pouvez posséder.
Donc toute critique est bonne à prendre si elle est fondée.

[e-ric]

Pour avoir de l'égo, il faut une "maîtrise" du code ou un bagage de développement étayé

Bof, pas de relation évidente entre l'égo et la compétence. C'est plus du ressort de la personnalité que de l'activité. Ceci dit un incompétent avec un gros égo est franchement un sale type.

Donc toute critique est bonne à prendre si elle est fondée.0

Je n'ai pas contesté cela.

Ce que je conteste surtout, c'est :
- la façon de présenter les arguments qui sont culpabilisants, assez '"bateau" pour pas dire infantiles pour certains ("Percevez chaque changement (outils, besoins, plateformes, etc.) comme un nouveau défi..", sympa dans la formulation, dans la pratique c'est la marche forcée avec un peu de pommade, au final on dirait les résolutions du nouvel an)
- Le fait qu'en informatique, le mauvais type est toujours le développeur, sans considération de son environnement, de sa charge de travail et des autres personnes qui participent aux développements sans coder (MOA, chef de projet). Je ne rejette pas les problèmes sur les autres mais c'est toujours plus facile de la mettre sur celui qui met les pattes dans le cambouis. On peut même l'accuser des bug propres à l'OS ou liés aux infrastructures (je plaisante à peine)

Si les développeurs avaient un peu plus d'égo, au sens de la fierté du travail bien fait, les logiciels seraient sans doute mieux écrits. Mais bon c'est sans doute passé de mode.

[e-ric]

Le "développeur sans égo" ne devrait il pas, par principe, renoncer à toute propriété / paternité sur le code produit?.

Tu parles d'une innovation, c'est juridiquement le cas, as-tu déjà déposé un programme à l'APP ? C'est pas un problème d'égo, c'est de l'ordre de ton contrat de travail.

De toutes façons, le dév : c'est tu reprends le code existant et tu fais au mieux pour répondre aux exigences avec les moyens qu'on te donne (quand on t'en donne), le reste c'est du pipeau.
Les grands discours, c'est du marketing ou de l'écran de fumée.

@+

[phili_b]

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

Quand objectivement plusieurs solutions sont acceptables, évidemment qu'il ne sert à rien de dire "je vous l'avais bien dit" s'il y a un souci à la fin. Mais quand par exemple on se trouve face à en face d'un chef de projet qui se fait mousser, qui ne connait pas la technique et qui à la fin râle parce que ça ne marche pas, alors qu'on lui avait dit que ce produit n'accepte que telle façon de faire, ou alors il change de produit, alors oui c'est jouissif de lui dire "je te l'avais bien dit" même si on se fait tirer les oreilles après. Le respect c'est dans les 2 sens, comme pour le sens des responsabilités : il a décidé de faire cela, en dépit de ce qu'on avait dit, ben qu'il en prenne la responsabilité. (Idem pour un autre dév, autre interlocuteur).

Je préfère les chefs de projet (dév, interlocuteur) se disant incompétent dans un domaine technique, et n'imposant pas leur vue technique, qu'un chef de projet (dév, interlocuteur) imposant des vues techniquement bancales.

Mais dans l'article initial il y a plein de faux bon-sens et de vrais problèmes que feint de ne pas comprendre Jeff Atwood et qu'expliquent très bien e-ric et Apad par exemple. Et surtout comme si ça n'existait que chez les développeurs comme dit sekaijin: ça fait quand même 40 ans que l'informaticien dans sa tour d'ivoire est en voie de disparition. Les informaticiens ont besoin d'être communicants aussi.

Le problème c'est que dans certains projets, les gens se réunissent dans des salles, décident....et demandent l'avis des informaticiens à la fin sans aucune marge de manœuvre, sans les impliquer.