Discussion :

[FR119492]

Salut à tous.

Voici une anecdote vécue qui illustrera non pas ce qu'est un professionnel (personne ne l'est ni toujours, ni tout à fait), mais une approche professionnelle d'un problème.

Un jour, un réseau électrique à moyenne tension a été déclenché brièvement puis réenclenché, afin de mettre hors service une petite ligne en vue de coupes forestières. Lors du réenclenchement, il a semblé ne rien se produire d'anormal, mais, environ 35 minutes après, une gigantesque explosion s'est produite dans la sous-station. Quand je dis gigantesque, ça veut dire les éclats de porcelaine des isolateurs incrustés dans le crépis des murs, les bobinages du transformateur tordus en tous sens comme si King Kong était passé par là, etc. Alors, le directeur des forces motrices m'a fait venir et m'a dit: "Résolvez-moi ce problème". Comme cahier des charges, c'est assez succinct.

Comment aborder un tel problème ? La première étape a été d'aller en fin de journée dans les divers bistrots de la localité, et de boire des demis avec les ouvriers. Eux ne connaissaient pas la théorie, mais ils avaient peut-être observé des choses importantes. L'ouvrier lambda ne parle pas volontiers de faits anormaux dans le bureau du directeur. Il dit des choses beaucoup plus intéressantes devant un demi. De ces discussions, j'ai déduit qu'il devait s'agir d'un phénomène de ferrorésonance, dont en fait je ne connaissais pas beaucoup plus que le nom, et c'est sur cette base que j'ai pu modéliser le phénomène, le simuler sur ordinateur et proposer les moyens de faire en sorte qu'il ne puisse plus se reproduire à l'avenir.

Tout ça pour vous dire que le développeur doit être "tout-terrain". Les problèmes qu'on lui soumettra viendront de gauche et de droite, et il devra être capable d'improviser en fonction des besoins, d'apprendre de cas en cas ce qu'il ne sait pas encore. A titre d'exemples, durant ma carrière, j'ai été amené à calculer le rendement thermodynamique d'un moteur diesel, le refroidissement de gros turboalternateurs, les réactances de machines synchrones, les phénomènes magnétohydrodynamiques dans les fours de production d'aluminium, la diaphonie dans les câbles téléphoniques, les estimateurs d'état sur les grands réseaux électriques, et j'en passe.

Pour terminer, est-ce que ce qui distingue un pro d'un bidouilleur, ce n'est pas ce qu'on pourrait appeler sa culture générale, que l'on qualifie de générale parce qu'elle concerne à la fois l'ensemble des domaines dans lesquels il peut être appelé à développer, l'algorithmique, dans lequel se font les pires horreurs (voir certains de nos forums) et les techniques strictement informatiques (matériel et logiciel) ? Et ça prend du temps pour acquérir ces compétences.

Jean-Marc Blanc

[souviron34]

Compares avec ce que tu as du connaître il y a 15 ans. Je suppose que tu vois du changement.

Exact, mais pas forcément dans le bon sens

Il y a beaucoup plus de communication tous les jours avec les utilisateurs, mais beaucoup moins de maitrise du "tout", comme dit Jean-Marc, et du coup une approche plutôt "patchage" que globale.

Pour te dire la vérité, le projet actuel marche depuis 30 ans; Créé en Fortran, transformé en C dans les années 90. Ce que je vois de ce qui se fait depuis 3 ou 4 ans est en train de totalement détruire l'architecture cliare et censée de l'époque pour la remplacer par un fouillis innommable (et bien évidemment je le crains totalement ingérable) de patchage de concepts objets mal pensés et mal isolés (en plus d'être mal programmés) .

Parce que le responsable global est jeune et brillant, mais n'a pas une grande expérience de choses de cette taille et longévité (c'est son 2ième boulot), et qu'il n'a appris que le C++ et les méthodologies objets, et qu'il est confronté à un immense logiciel ... Parce que les programmeurs sont jeunes (première expérience après CEGEP, ou Ingénieur ou maîtrise). Et parce que, comme le dit Jean-Marc, il n'y a pratiquement personne (tous les anciens sont partis) qui aie une culture générale et une expérience assez grande pour appréhender "simplement" quelque chose de cette envergure et touchant autant de domaines.

Disons que mon expérience actuelle ne fait pas ressortir de façon flagrante une amélioration..

Dans la communication, oui.. Dans la pensée et le résultat (structurel en particulier), non.... et même au contraire... (ce qui est quand même le but de l'industrie)...

Comme le dit Jean-Marc, je pense qu'à cause d'un manque de formation générale, de réflexion ou d'apprentissage sur les "concepts" de pensée, c'est plutôt une application de concepts de méthodologies ou langages que des concepts de pensées ou architectures "absolues"...

[Garulfo]

[...]
Parce que le responsable global est jeune et brillant, mais n'a pas une grande expérience de choses de cette taille et longévité (c'est son 2ième boulot),[..]

Moi je te dirais que le problème que tu cites vient de là.
Il est là le bonhomme qui doit avoir une vue d'ensemble.
S'il ne sait pas si prendre, ça pose problème.

Si c'est ça que tu voulais dire, je suis d'accord. Mais ce n'est pas ce que j'ai compris. Pour moi, vous dites que tout devrait être fait par une seule personne. Je pense que d'une part c'est impossible en pratique pour les projets, et que d'autres part c'est extrêmement risqué au niveau fiabilité globale. Mais des équipes distinctes imposent une bon gestionnaire de projet (ce qui n'a rien à voir avec un bon technicien).

[souviron34]

Pour moi, vous dites que tout devrait être fait par une seule personne. .

euh.. je crois que tu nous as mal compris (en tous cas moi)

Du tout.. Ce qu'on (enfin en tous cas moi) disons (dit), c'est que les methodes nouvelles n'ont pas amene grand chose dans la pratique, car on confond encore technicite et intelligence.

Et ce n'est pas une seule personne, mais un ensemble de personnes ayant des points de vue divers et ouverts qui amenent a quelque chose de brillant..

Ce qu'on faisait remarquer par rapport au post en reference, c'est que les "experts techniques", d'un cote comme de l'autre, doivent avoir une culture "mixte", et non specifique. Et que, si les experts "metiers" doivent etre (au besoin) encadres pour amener plus de rigueur dans l'expression (par exemple avec une approche ergonomique), cela prend du cote informatique un gestionnaire/chef de projet/architecte qui soit a meme non seulement de comprendre le point de vue utilisateur, mais de l'avoir suffisamment integre pour le prendre en compte en permanence.

En ce sens, cela pourrait eventuellement etre ramene a une personne, mais c'est mieux quand toute l'equipe fonctionne sur le meme mode..

Disons en gros que etre informaticiien forme aux "bonnes" methodes (comme celles que tu cites) , fonctionnant dans une equipe du meme genre, ayant de plus a disposition une equipe d'utilisateurs et une methode XP, ne garantit en rien la production d'un bon logiciel.

Tout au plus cela garantit qu'on ne s'eloignera pas trop des demandes des utilisateurs.

Mais on peut faire une usine a gaz pour y arriver... Et ne gerer les changements possibles qu'au coup par coup..

D'ou le rapport entre bidouilleurs et pros..

Ce qu'on veut dire, c'est que dans notre conception, un vrai pro non seulement produit un logiciel repondant a la demande, mais de plus documente, facilement maintenable et extensible, que ce soit du point de vue informatique (outils etc..) que du point de vue demande des utilisateurs ou variations du cahier des charges... Et que donc une formation "large" mais "scientifique" (dans le sens rigueur) est bien plus garante de reussite que une bonne maitrise technique d'un outil ou d'une methode...

(suffit de regarder les posts dans le sous-forum "Methodes", ou le but semble etre la creation de MCD, diagrammes de classes, etc.., en oubliant le fond, que ce ne sont que des outils, et que la conception est une affaire intellectuelle, n'ayant qu'un lointain rapport avec la forme avec laquelle on la represente...

Je reviens a ma citation preferee : "Ce qui se concoit bien s'enonce clairement"...
)

[GrandFather]

Ce qu'on veut dire, c'est que dans notre conception, un vrai pro non seulement produit un logiciel repondant a la demande, mais de plus documente, facilement maintenable et extensible, que ce soit du point de vue informatique (outils etc..) que du point de vue demande des utilisateurs ou variations du cahier des charges... Et que donc une formation "large" mais "scientifique" (dans le sens rigueur) est bien plus garante de reussite que une bonne maitrise technique d'un outil ou d'une methode...

Ok, une tête bien faite vaut mieux qu'une tête bien pleine, touça... Mais tout ce que tu décris comme étant les vertus d'un développeur "pro" sont enseignées aujourd'hui dans les cours de génie logiciel. Et si elles ne sont pas correctement appliquées par les développeurs sortant de formation, il ne faut s'en prendre qu'à leur inexpérience, pas aux méthodes elles-mêmes. On ne devient pas "pro" immédiatement, au début on doit composer entre un enseignement plus ou moins bien digéré, la pression du premier job, l'angoisse d'avoir à faire ses preuves dans un secteur très compétitif et... son enthousiasme. Après, progressivement, les choses se mettent en place.

Peut-être que, étant très brillant, tes débuts n'ont pas été aussi laborieux, mais ça ne doit pas être le cas de la majorité des développeurs quel que soit leur cursus. Dans le cas que tu exposes, le choix d'un chef de projet inexpérimenté est manifestement une erreur stratégique.

[Garulfo]

euh.. je crois que tu nous as mal compris (en tous cas moi)

Du tout.. Ce qu'on (enfin en tous cas moi) disons (dit), c'est que les methodes nouvelles n'ont pas amene grand chose dans la pratique, car on confond encore technicite et intelligence.[...]

Bon alors effectivement je n'ai pas du tout compris ça

[nikko34]

le pro, c'est celui qui vit du développement non?

[souviron34]

disons en gros que ce qu'on dit c'est qu'il ne suffit pas que, comme tu le dis, Garulfo, d'etre "programmeur".

Et que, la ou nous sommes tous d'accord, GrandFather, Garulfo, Jean-Marc, et moi-meme, c'est pour dire que des que l'on commence a additionner "analyste" a "programmeur", et pour les fonctions au-dessus (chef d'equipe, architecte, chef de projet, etc..), il faut imperativement posseder un minimum des connaissances du metier, ou a tout le moins etre pret a les assimiler tres vite, et etre en discussion permamente avec les utilisateurs.

J'ai toujours considere, de toutes facons, que la division du travail du monde informatique etait absurde.... Un "programmeur" simple ne fait qu'appliquer des directives, qui lui sont pseudo-traduites par l'analyste, qui lui-meme les a pseudo-traduites des utilisateurs...

Et donc, ce que nous defendions avec Jean-Marc, c'etait de dire que suivant notre point de vue et experience, un bon "programmeur" etait avant tout quelqu'un capable de prendre la responsabilite du haut en bas au moins d'une partie du soft (une fonctionalite par exemple) : du dialogue a la conception a la programmation...

Ca ne veut pas dire etre exceptionnel, mais simplement plus qu'un simple "guru technique".

Et je repete (pour GrandFather ) que ce que j'appelais "mode scientifique" etait plus du bon sens et de la logique qu'autre chose, et que les nouvelles methodes ne semblent pas produire plus de ca que les anciennes.... (pour s'en convaincre, en dehors des experiences actuelles de chacun, les posts sur DVP sont un bon exemple..... )

[el_slapper]

Bon, j'ai tendance à faire partie du courant souvironien, là.....

parceque bon, certes les méthodes modernes sont très puissantes. Mais comme tout outil, il n'a de sens que correctement utilisé. Exemple vécu dans une très grande banque Française :

un projet est lançé par un DP. il recrute un CP indépendant, un vieux de la vieille qui connait tous les trucs. Le CP senior recrute son équipe en cherchant les meilleurs - peu importe si ce sont de sales cons. Seuls les homologateurs(dont moi, pour une fois pas développeur) lui sont imposés. Et il a une équipe de superbêtes, qui avance très bien malgré un contexte difficille. Peu après, suite à une réorganisation, le projet tombe sous la responsabilité d'une nouvelle DP - très expérimentée, mais surtout très peu compétente(eh oui, ça arrive).

Parmi les recrues du CP était un spécialiste UML. Qui a donc traduit les expressions de besoin fonctionelles des utilisateurs en UML. C'était magnifique. Je me suis basé là-dessus pour préparer mes cas-tests, et ce fut un plaisir. Pendant ce temps là, les specs sont présentées à l'urbanisme pour validation. Validation accordée avec félicitations. Jusque là, un rêve.....

qui se transforme en cauchemar quand la DP insulte l'urbanisme car un "assistant extérieur n'est jamais digne de recevoir des félicitations". Tout le monde (sauf les homologateurs) est viré progressivement, remplaçé par des petits jeunes qui ne connaissent pas leur boulot, qui mélangent UC et écrans dans les specs, transformant du parfaitement clair en bouillie infâme, la nouvelle CP ne comprend même pas la différence entre charge et délai(parceque oui, quand on trouve une anomalie et que les progs corrigent, il faut repasser le cahier de tests, mais ça, elle a jamais compris), et les homologateur démissionnent avant d'être accusés d'incompétence par des gens même pas capables de pondre une aide correcte.

En bref : peu importe la méthode, si les gens derriere ne suivent pas, c'est la fin des haricots.

[GrandFather]

Et que, la ou nous sommes tous d'accord, GrandFather, Garulfo, Jean-Marc, et moi-meme, c'est pour dire que des que l'on commence a additionner "analyste" a "programmeur", et pour les fonctions au-dessus (chef d'equipe, architecte, chef de projet, etc..), il faut imperativement posseder un minimum des connaissances du metier, ou a tout le moins etre pret a les assimiler tres vite, et etre en discussion permamente avec les utilisateurs.

Nous sommes effectivement d'accord, tout cela est nécessaire pour pouvoir cumuler toutes les "casquettes". Cependant, deux remarques : toutes les structures et tous les projets ne permettent pas cette polyvalence, d'autre part il faut pour cela une "culture du projet" qui ne s'acquiert qu'avec l'expérience et beaucoup de temps et d'efforts. Exiger cela de développeurs qui débutent n'est pas très réaliste...

J'ai toujours considere, de toutes facons, que la division du travail du monde informatique etait absurde.... Un "programmeur" simple ne fait qu'appliquer des directives, qui lui sont pseudo-traduites par l'analyste, qui lui-meme les a pseudo-traduites des utilisateurs...

Ca, c'était l'approche mini et gros système, qui est progressivement abandonnée. cette nomenclature demeure, notamment dans les grands comptes, mais plus pour justifier les différences salariales entre développeurs "seniors" et "juniors", que révélatrice d'un mode de fonctionnement des équipes de développement.

Et je repete (pour GrandFather ) que ce que j'appelais "mode scientifique" etait plus du bon sens et de la logique qu'autre chose, et que les nouvelles methodes ne semblent pas produire plus de ca que les anciennes.... (pour s'en convaincre, en dehors des experiences actuelles de chacun, les posts sur DVP sont un bon exemple..... )

Je souhaite bonne chance au développeur qui compte faire carrière sans faire preuve de sens logique et de pragmatisme...

Il est un peu trop facile de disqualifier les méthodes modernes de développement au vu des questions posées sur DVP ; elles sont souvent le fait le fait de débutants (au sens non péjoratif du terme) qui n'ont pas encore fait complètement le lien entre un savoir théorique et son application pratique. Plus significatives à mon avis sont les réponses apportées à ces questions, quand elles viennent de développeurs expérimentés qui ont saisi la philosophie sous-jacente de ce qui n'apparaîtrait sinon que comme une collection de recettes absconses et fastidieuses. Pour prendre un exemple, on ne peut être totalement convaincu par la pertinence d'une modélisation objet permettant l'évolutivité que lorsqu'on a été soi-même confronté à la nécessité de faire évoluer fonctionnellement une application complexe, surtout quand on n'a pas participé au développement initial. L'avoir appris en cours est une chose, en être imprégné et l'appliquer efficacement en est une autre. Mais ça ne tombe pas du ciel, ca exige d'avoir un peu de bouteille...

[souviron34]

Exiger cela de développeurs qui débutent n'est pas très réaliste...

Entierement d'accord, mais on discutait de "pro vs bidouilleur", et non debutant vs experimente...

L'avoir appris en cours est une chose, en être imprégné et l'appliquer efficacement en est une autre. Mais ça ne tombe pas du ciel, ca exige d'avoir un peu de bouteille...

Absolument...

Et c'est pour ca que je maintiendrais que les methodes, qu'elles soient anciennes ou modernes, ne sont pas la panacee...

Et qu'il vaut mieux une equipe de "brillants" avec une ancienne methode qu'une equipe de "mediocres" avec une nouvelle methode...

D'ailleurs, ca me rappelle quelque chose..

Le tres gros projet medical sur lequel j'avais travaille il y a plus d'une dizaine d'annees (dont j'ai cite quelques faiblesses dans d'autres posts sur ce forum ou sur le sous-forum methodes ou conception, je ne me souviens plus)... :

• L'architecte general (qui etait la depuis le debut), confronte aux resultats impressionnants de notre equipe de 6 travaillant en style "XP" obtenus en moins d'un an, doit discuter avec le directeur technique general pour mettre au point la reprise par son equipe (60 personnes) de ce que nous avions fait.
  Avec une date limite de terminaison 8 mois plus tard.
  
  
• Quand je lui conseille de nous garder, et de nous adjoindre 6 personnes de plus au maximum, il me dit "Ah .. Vous coutez trop cher .. Et vous ne fonctionnez pas suivant ma methode..".. .
  
  
• Je lui repond alors : "En 8 mois, si tu veux faire quelque chose d'extra-ordinaire, il te faut une equipe extra-ordinaire".
  
  
• Et sa reponse : "Mon defi est de faire quelque chopse d'extra-ordinaire avec des gens ordinaires"...
  
  
• Donc il garde son equipe, et pour nous remplacer embauche 20 debutants de plus.
  
  
• La boite a ferme 10 mois plus tard, car incapable de livrer le produit...
  (apres avoir depense 80 millions de dollars !!!!)

[davcha]

souviron34, donc tu te définis comme pro ou bidouilleur ?...

[souviron34]

souviron34, donc tu te définis comme pro ou bidouilleur ?...

je me definis comme un artisan... professionnel..

Bidouilleur certainement pas.

Pro : encore une fois tout depend de ce qu'on met dessous..

Je gagne ma vie avec (quoi que...). J'ai 25 ans d'experience industrielle. J'ai dirige, concu et programme des applications operationnelles critiques, pour certaines quasi-seul. Mon code est repris et maintenu par d'autres. J'applique des regles et des normes.. Mais pas a la lettre... Idem pour les methodes... Je reflechis avant de programmer. Je concois des architectures globales.. et je reflechi aux consequences a long terme...

Quand je fais un travail, non seulement moi j'en suis fier, mais mes clients aussi...

Mais je n'applique pas ni les normes ni les methodes a la lettre.
Mais je ne suis pas forcement les etapes du cycle de vie.
Mais je n'utilise pas forcement toutes les subtilites des langages.
Mais je ne rentre dans aucun des cadres de "decoupage traditionnel du travail en info"
Mais etc etc...

[davcha]

Donc, pour résumer, tu adaptes tes solutions et tes méthodes de travail aux situations, en tenant compte du fait que ces situations peuvent, dans certains cas, évoluer.

En gros, plutôt que d'appliquer bêtement une recette, sans réfléchir, tu analyses la situation et fais des choix, que tu es capable d'expliquer, dans les détails.
Du coup, tu es convainquant vis à vis de ces choix, tes clients sont rassurés et contents, etc...

A mon avis c'est ce que font la très grande majorité des développeurs (c'est peut-être optimiste de penser ça, ceci dit...). Tout du moins, c'est ce que devraient faire tous les développeurs.


A partir de là, est-ce que le débat se résume vraiment juste à "quelle est la différence entre quelqu'un qui réfléchit et un robot ?".... ?
Parce que le débat met clairement le "pro" en opposition avec le "bidouilleur", et si on dit que le "pro" est quelqu'un qui réfléchit, alors le bidouilleur est quelqu'un qui ne réfléchit pas ? ou qui réfléchit "mal" ?
Là du coup, j'ai l'impression qu'on se retrouve avec l'espèce de gag bien connu : "La différence entre un bon et un mauvais programmeur : Le mauvais programmeur, il code, il compile, il exécute et ça plante.
Le bon programmeur, il code, il compile, il exécute, ça plante mais
c'est un bon programmeur..."

C'est un peu caricatural, évidemment, mais je trouve ce débat vraiment trop évasif, en fait.
Sans viser personne, parce que vu le manque de précision du sujet, j'imagine mal comment on aurait pu arriver à autre chose que ça : je trouve que ce topic ressemble plus à un topic où chacun se lance joyeusement des fleurs en se comparant à un "autre" plus ou moins hypothétique qui est tellement "mauvais" qu'on se demande comment il fait pour gagner sa vie.

[divagations ayant un rapport très lointain avec le sujet]
C'est dommage quelque part d'ailleurs de se comparer à un "nul", que ce soit pour se rassurer, pour sa gloire personnelle ou quoique ce soit d'autre.

Je sais que ce n'est pas ce que tu fais souviron, au cas où tu te serais senti visé, j'ai lu suffisamment de tes posts pour me rendre compte que c'est pas ton genre. L'exemple que tu donnes, assez souvent d'ailleurs :p, sur ce projet médical que tu as mené plus ou moins en parallèle avec cette équipe de 60 gars qui utilisaient une méthode V ou waterfall, me souviens plus exactement... Tu nous racontes une anecdote qui illustre assez bien que la méthode ne fait pas tout.
Bref, ne prends surtout pas ces divagations personnellement

Donc, disais-je, dommage comme certains (pas forcément sur ce forum d'ailleurs) aiment se comparer à des "nuls", quelles qu'en soit les raisons, parce que c'est pas de cette manière qu'on s'améliore.
[/divagations]

En bref, après avoir lu les dernières interventions sur ce sujet, je trouve toujours qu'en dehors de quelques anecdotes rigolottes, c'est un mauvais sujet.

On peut se demander pourquoi je prends le temps d'y répondre du coup.
(on va mettre ça sur le compte de ma sinusite)

[GrandFather]

Entierement d'accord, mais on discutait de "pro vs bidouilleur", et non debutant vs experimente...

Pour moi c'est lié : en début de carrière c'est le règne de la bidouille, de l'empirisme et de l'application pas toujours à bon escient de méthodes (mal) assimilées durant la formation. Ce n'est qu'avec l'expérience que progressivement on se "professionnalise". La vitesse d'évolution dépend d'un individu à l'autre, et certains n'atteignent jamais ce cap. Mais bon, ils ont généralement les évolutions de carrière et le salaire qui va avec...

[Singular]

C'est étonnant de voir à quel point le sujet peut être pris selon différents angles.

Mais, pour revenir au point de départ je redonne mon avis sur la question.

Un bidouilleur, ce n'est qu'un bidouilleur. Il n'a, par définition, pas de méthode éprouvée. Il bidouille. Il tâtonne et arrive à des résultats étonnants mais difficiles à suivre pour d'autres programmeurs.

Un "pro" peut lui aussi bidouiller de temps à autres. Mais ça ne fait pas de lui un bidouilleur car il est capable de fonctionner dans un cadre organisé, avec méthode.

Le pro n'est un pro dans aucun autre domaine que la programmation et le développement. Il n'en a pas besoin. Il est sans doute capable d'apprendre sur tous les sujets puisqu'il a, règle générale, passé à travers des tonnes de concepts abstraits pendant sa formation afin de décrocher un diplôme.

On peut toujours invoquer les génies, les fous de l'informatique qui ont des verres épais comme des fonds de bouteilles et pas de vie sociale et qui ont tout appris par eux-mêmes pour invalider ce que je viens de dire, mais ce ne sont toujours pas des pros; ce sont des génies.

"Pro" vient du mot "professionnel". Pas de "miraculeux" ni de "extraordinaire". Il ne sous-entend pas autre chose que le professionalisme du sujet dans son domaine. Et, le professionalisme en programmation, c'est d'avoir une méthode qui ne produit pas du code spaghetti et/ou bogué. Ça n'a rien à voir avec le monde artistique où tout est subjectif.

La méthode, ce n'est pas facultatif. Comme l'orthographe, la grammaire, les mathématiques, il y a des règles à suivre. Quand on en sort, ça devient de la bidouille. On peut arriver à des résultats étonnant ainsi mais, je souhaite bonne chance aux coéquipiers d'un bidouilleur. C'est pour ça qu'un bidouilleur bidouille toujours seul, dans son sous-sol.

[el_slapper]

"Pro" vient du mot "professionnel". Pas de "miraculeux" ni de "extraordinaire". Il ne sous-entend pas autre chose que le professionalisme du sujet dans son domaine. Et, le professionalisme en programmation, c'est d'avoir une méthode qui ne produit pas du code spaghetti et/ou bogué. Ça n'a rien à voir avec le monde artistique où tout est subjectif.

La méthode, ce n'est pas facultatif. Comme l'orthographe, la grammaire, les mathématiques, il y a des règles à suivre. Quand on en sort, ça devient de la bidouille. On peut arriver à des résultats étonnant ainsi mais, je souhaite bonne chance aux coéquipiers d'un bidouilleur. C'est pour ça qu'un bidouilleur bidouille toujours seul, dans son sous-sol.

Je retiendrais finalement la fin de ta définition : le pro, c'est celui dont le travail est réutilisable dans un milieu professionel. Quelle que soit sa méthode, quel que soit son style, il a su créer un code, des documentations, des cas-tests(et j'en oublie surement) utilisables par d'autres en milieu professionel. Et ça, c'est bien plus important que la performance pure.

Parceque là, je suis en pleine phase de rétrodoc. Y'a du code qui a plus de 20 ans. Codé en 3 jours et qui fait plein de choses, et qui les fait bien. Sauf que c'est illisible, spaghetti, et que les docs ont disparu avant le mur de Berlin(je ne rigole pas, ça fait vraiment plus de 20 ans). Et comme il faut refondre pour augmenter la flexibilité du système, alors il faut savoir ce qu'il fait. Et c'est atroce.

Un pro aurait mis 15 jours, mais son code serait réutilisable facilement.

[deltree]

L'expérience apporte le côté "professionnel", oui.
Mais j'ajouterais que quand on met "les mains dans la cambouis", les méthodes ne semblent pas aussi carré que ça. Pour avoir fait de longues études, et appliqué les méthodes anciennes et nouvelles modélisation;Merise et UML; la méthode n'apporte pas les solution à tout, et le fait qu'une certaine expérience soit nécessaire montre que tout cela est assez empirique ,et de mon point de vue, pas vraiment cartésien.

Il y a des méthodes particulièrement éprouvées pour écrire des bases de données normalisées, des grammaires LL(n) LALR(n) parce que c'est parfaitement formalisé, et à la portée de n'importe quel jeune diplômé sans expérience mais qui travaille dans les règles de l'art.

En revanche, il n'y a pas de méthode absolue pour trouver l'algorithme le plus efficace, à par le bon sens, les transposition de problèmes déjà rencontré (ou étudiés). De même il n'y a pas de solution simple pour trouver la meilleure architecture face à un problème donné, là c'est plus fonction de l'expérience.

Quand j'ai commencé mes études et que j'étais un pur "bidouilleur", je croyais réapprendre ce que je savais de façon correcte, or j'ai appris beaucoup plus, mais pas uniquement à coder, davantage à concevoir, laissant ainsi une certaine zone d'ombre entre la spécification, et le passage au code.
On peut-être analyste sans savoir bidouiller, on peut être un (mauvais) programmeur sans avoir de méthode, mais on peut difficilement être un programmeur tout court sans un minimum d'auto apprentissage, ce qui seul et sans méthode conduit effectivement à la "bidouille".

[GriffinK]

Vous parlez de bonnes méthodes de codage, je suis curieux de savoir ce que vous entendez tous par là...existe t-il un ouvrage ou encore un site qui me permettrait voir tout ça ?

[Singular]

Pour ce qui est des ouvrages sur le sujet, ils sont très nombreux et la plupart sont en Anglais. Mais en suivant les liens (de Wikipedia) ci-dessous, tu auras une bonne idée de départ de ce qui est en cause ici.

Programmation structurée
Extreme Programming
Technologie Bottom-Up
Technologie Top-Down
Programmation orientée Objet

La version anglaise de ces articles est plus complète que la française.

Si ton Anglais est bon, un livre me vient à l'esprit: Code Complete de l'auteur Steve McConnell aux éditions Microsoft Press. Il traite d'un peu tous les aspects reliés au métier de programmeur et établit des standards logiques et utiles à suivre pour cesser de s'arracher les cheveux lorsqu'on travaille en équipe ou sur de gros projets.

Le sujet (la bidouille vs le professionalisme), comme tu peux le voir dans la suite de messages qui se sont accumulés, est mal balisé et peut être vu selon plusieurs angles.