Discussion :

[jabbounet]

Et encore, expérience et âge sont deux choses différentes. Un gars de 20 qui a toujours été passionné, qui a grandi parmi les ordis et qui code depuis qu'il a 10 ans peut avoir plus d'expérience qu'un autre de 30 ans qui a commencé à 20 ans à la fac...

Il aura la compétence technique pour faire du dev propre dans tel ou tel langage la je n'ai aucun doute la dessus. mais qu'en sera t'il des aspects fonctionnel et métiers?

Pour avoir rouler ma bosse dans deux ou trois domaines sur dix ans même si les langages sont les même les aspects métiers peuvent parfois diverger du tout au tout.
L'informatique embarqué temps reel dans des systèmes type avion/train/centrale nucléaire n'a pas grand chose à voir avec le SI d'un operateur de teléphonie ou d'un acteur de l'industrie automobile.

Même si une partie des technos est equivalente voir identique les contraintes métiers sont tellement divergente que de l'experience dans un domaines et une compréhension fine du métier des personnes avec qui tu travaille peu vraiment apporter un plus dans les phases de conception/developpement/test d'applications et t'éviter de pondre un truc inadapté qui ne sera pas ou peu utilisé.

Maintenant on ne me fera pas croire qu'un jeune sorti d'école aura une compréhension aussi fine de l'un des métiers évoqué que quelqu'un qui en a fait son métier (sauf le cas de personnes qui ne comprennent rien et n'apprennent pas) à moins d'avoir fait une partie non négligeable de sa formation au contact de personnes du dit métier.

[Alain Defrance]

Il aura la compétence technique pour faire du dev propre dans tel ou tel langage la je n'ai aucun doute la dessus. mais qu'en sera t'il des aspects fonctionnel et métiers?

Pour avoir rouler ma bosse dans deux ou trois domaines sur dix ans même si les langages sont les même les aspects métiers peuvent parfois diverger du tout au tout.
L'informatique embarqué temps reel dans des systèmes type avion/train/centrale nucléaire n'a pas grand chose à voir avec le SI d'un operateur de teléphonie ou d'un acteur de l'industrie automobile.

Même si une partie des technos est equivalente voir identique les contraintes métiers sont tellement divergente que de l'experience dans un domaines et une compréhension fine du métier des personnes avec qui tu travaille peu vraiment apporter un plus dans les phases de conception/developpement/test d'applications et t'éviter de pondre un truc inadapté qui ne sera pas ou peu utilisé.

Maintenant on ne me fera pas croire qu'un jeune sorti d'école aura une compréhension aussi fine de l'un des métiers évoqué que quelqu'un qui en a fait son métier (sauf le cas de personnes qui ne comprennent rien et n'apprennent pas) à moins d'avoir fait une partie non négligeable de sa formation au contact de personnes du dit métier.

Oui je suis tout à fait d'accord, le métier c'est le plus difficile à cerner. Enfin après on est vraiment concerné par le métier soit dans de petites boites, soit lorsqu'on s'oriente vers le fonctionnel. Et là le fonctionnel c'est un autre métier, c'est plus développeur, malheureusement en France on part du principe qu'un bon développeur devra partir sur du fonctionnel ... dommage ...

[Chico el guacamole]

Bonjour à tous

Il y a 2 ans, sur Lyon, dans une SSII, un jeune embauché qui eu pour mission de récupérer en java une liste d'image jpeg dans un répertoire.
comme il avait brillamment remarqué que les images pouvaient s'écrire avec l'extension jpg ou JPG il a eu l'intelligence de griffoner sur un papier ce qu'il s'apprétait à faire : 'jpg, jpG, jPg, jPG, ....JPG'
construire un tableau pour valider les extensions, mais c'est naze !, même dans un autre langage, on testerait les noms en minuscule.
j'en ri encore.

Je me rappelle que c'est cette même personne qui ne sortait pas des boucles quand il avait trouvé ce qu'il cherchait, ça ça m'énèrve !
par exemple :

Code :

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

1
2
3
4
5
  boolean found=false;
  for ( int i=;i<1000000000000;i++) {
      if (i==3) found=true;
   }

dans une boucle avec plus d'instruction lorsque l'on relit le code on se demande toujours pourquoi

Enfin pour les chefs de projets de notre client principal de l'époque, la politique de création des shells KSH était de ne pas faire de fonctions, de ne pas factoriser le code, je vous laisse imaginer les copier/coller et ce que je pense de cette hérésie

allez comme c'est vous une dernière dans ces scripts KSH :

Code :

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

1
2
3
4
5
6
7
8
9
   if [ $* -ne  2 ]; then
       echo "Nombre de parametres incorrect"
       exit 1
   else
      blablabla
   fi

   blablabla2

j'ai peut-être tort mais le exit et le else me semble redondant, le code 'blablabla' et 'blablabla2' étant toujours éxecuter ensemble

le pire que j'ai fait ?
à mes débuts, une parmi tant d'autres, une fonction de 600 lignes.
et vous ?

le pire que j'ai vu
un programme C en un fichier de 17000 lignes, réductible à 2000 lignes si les règles de factorisation simples avaient été faites et le code mort enlevé.

je rends l'antenne

a tcho

[kpouer]

Tu as raison, il y a des "experts" de tous ages. Quoique, "expert jeune", quelque part, c'est un oxymore!

dans beaucoup de cas oui mais ca dépend aussi de l'age auquel une personne commence. Un exemple, le concepteur d'origine de jEdit a commencé le projet en 1998, il avait 14 ans, on peut considérer qu'à 20 ans c'était un expert java je pense vu la durée d'expérience et le projet

[Alain Defrance]

dans beaucoup de cas oui mais ca dépend aussi de l'age auquel une personne commence. Un exemple, le concepteur d'origine de jEdit a commencé le projet en 1998, il avait 14 ans, on peut considérer qu'à 20 ans c'était un expert java je pense vu la durée d'expérience et le projet

Après faut se méfier. J'ai travaillé sur un gros projet dans une SSII et ils avaient mis un expert Java de 19 piges sur le projet ... Et ben bonjour les dégâts ... incroyable !
Paradoxalement il y a beaucoup d'experts reconnus, auteur de livre, d'une trentaine d'année voir moins, donc expert à 20 piges c'est chaud, mais bon ça peut venir rapidement.

J'ai commencé à programmer vers 14 également, je n'ai jamais arrêter, j'ai maintenant suffisamment d'assurance pour aborder un projet gros sereinement mais je suis très très loin de me considérer comme expert ...
Penser qu'on sait tout ou que l'on maîtrise totalement un sujet c'est aussi bloquer notre propre progression ...

Par ailleurs il y a expérience et expérience. On peut travailler 20 ans sur des projets de merdes ou tu chie des vue/action toute la journée sans acquérir aucune expertise. Il y a des projets qui s'y prêtent d'autres non.

[kpouer]

Oui c'est sur, mais quand après 6 ans de dev on arrive a 20 ans et qu'on a fait tout seul ou presque un projet pas vraiment grand public et pourtant utilisé par 2 millions d'utilisateurs, on est quand même un cas a part. D'ailleurs c'est marrant parce qu'il a complètement switché, ne fait plus de java, maintenant il est sur son propre langage de programmation

[Alain Defrance]

Oui c'est sur, mais quand après 6 ans de dev on arrive a 20 ans et qu'on a fait tout seul ou presque un projet pas vraiment grand public et pourtant utilisé par 2 millions d'utilisateurs, on est quand même un cas a part. D'ailleurs c'est marrant parce qu'il a complètement switché, ne fait plus de java, maintenant il est sur son propre langage de programmation

Justement, travailler tout seul c'est différent de travailler à plusieurs ...
Ils s'appel comment ce langage ?

[kpouer]

C'est Factor :
http://factorcode.org/

Un langage vraiment bizarre mais c'est marrant, on peut vraiment faire plein de choses avec, de l'appli lourde ou web (d'ailleurs le site web lui même est hébergé par un serveur web programmé en Factor avec le langage de scripting web de factor).
Bon je sais pas a quoi ca va aboutir au final mais je trouve que le défi était intéréssant

[covao]

langage Brainfuck et Ook

[Alain Defrance]

Bon je sais pas a quoi ca va aboutir au final mais je trouve que le défi était intéréssant

Probablement pas grand chose, mais en tous cas c'est toujours des défis intéressants et enrichissants.

[Mac LAK]

Un gars de 20 qui a toujours été passionné, qui a grandi parmi les ordis et qui code depuis qu'il a 10 ans peut avoir plus d'expérience qu'un autre de 30 ans qui a commencé à 20 ans à la fac...

Un exemple, le concepteur d'origine de jEdit a commencé le projet en 1998, il avait 14 ans, on peut considérer qu'à 20 ans c'était un expert java je pense vu la durée d'expérience et le projet

Oui c'est sur, mais quand après 6 ans de dev on arrive a 20 ans et qu'on a fait tout seul ou presque un projet pas vraiment grand public et pourtant utilisé par 2 millions d'utilisateurs, on est quand même un cas a part.

Arguments fallacieux : si on va par là, à 35 ans, j'aurais 25 ans d'expérience dans l'informatique (ben oui, j'ai commencé à l'âge de 10 ans...), et j'étais expert avant même ma majorité ??

Restons réalistes : il n'y a aucune commune mesure entre ce que je faisais avant mon entrée dans le monde professionnel et ce que j'ai fait après. J'ai pourtant développé des choses réellement complexes avant de commencer à bosser, y compris un modeleur / renderer 3D à une époque où l'accélération 3D n'existait que sur quelques rares cartes pro hors de prix.
Mais ce programme n'était pas "pro" quoi qu'il en soit : il était mal documenté, mal commenté, mal découpé, n'était pas correctement prévu pour les évolutions et n'avait pas subi le dixième des tests qu'il aurait dû subir. Pourtant, "à l'œil", ça en jetait un max !! Mais ça ne change pas le fait que ce n'était pas du boulot "propre", ni professionnel, et que ça ne faisait absolument pas de moi un expert. Juste un gamin passionné qui se débrouillait pas mal avec du code.

C'est pour cela que je parlais d'expérience significative : lorsque l'on fait ça en dilettante et/ou en amateur, on ne se fixe pas le quart des contraintes que l'on a en entreprise. Or, c'est justement de savoir respecter ces contraintes qui fait qu'un boulot de développement est directement utilisable professionnellement, ou pas.

[jabbounet]

Bonjour à tous

Code :

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

1
2
3
4
5
6
7
8
9
   if [ $* -ne  2 ]; then
       echo "Nombre de parametres incorrect"
       exit 1
   else
      blablabla
   fi

   blablabla2

il n'y a pas que le exit qui gène. si je ne me trompe pas la façon de compter le nombre d'argument aussi non?

[Alain Defrance]

Arguments fallacieux : si on va par là, à 35 ans, j'aurais 25 ans d'expérience dans l'informatique (ben oui, j'ai commencé à l'âge de 10 ans...), et j'étais expert avant même ma majorité ??

Restons réalistes : il n'y a aucune commune mesure entre ce que je faisais avant mon entrée dans le monde professionnel et ce que j'ai fait après. J'ai pourtant développé des choses réellement complexes avant de commencer à bosser, y compris un modeleur / renderer 3D à une époque où l'accélération 3D n'existait que sur quelques rares cartes pro hors de prix.
Mais ce programme n'était pas "pro" quoi qu'il en soit : il était mal documenté, mal commenté, mal découpé, n'était pas correctement prévu pour les évolutions et n'avait pas subi le dixième des tests qu'il aurait dû subir. Pourtant, "à l'œil", ça en jetait un max !! Mais ça ne change pas le fait que ce n'était pas du boulot "propre", ni professionnel, et que ça ne faisait absolument pas de moi un expert. Juste un gamin passionné qui se débrouillait pas mal avec du code.

C'est pour cela que je parlais d'expérience significative : lorsque l'on fait ça en dilettante et/ou en amateur, on ne se fixe pas le quart des contraintes que l'on a en entreprise. Or, c'est justement de savoir respecter ces contraintes qui fait qu'un boulot de développement est directement utilisable professionnellement, ou pas.

Ce qui me gène c'est que visiblement d'après toi un expert c'est quelqu'un qui a une attitude pro. Pour moi c'est quelqu'un qui maitrise totalement son domaine d'expertise. Des gens qui savent travailler en entreprise (test u, test d'intégration, doc, utilisation de forge, redaction fonctionnel, savoir lire une use case, diagramme, découper une application par lot, anticiper les prioritées, tenir ses deadline, et j'en passe) il y en a des milliers. Mais des gens qui conaissent JEE en profondeur il y en a très peu.
Je pense qu'il y a une césure énorme entre un pro et un expert. Bien évidement c'est lié, on est pas confronté a de gros systèmes (plusieurs centaines de milliers de classes) dans un cadre personnel, et donc on ne peut pas être confronté à toute la compléxité d'une grande application seul, ni aux contraintes du monde pro. Mais travailler seul n'empeche pas d'être pointu, et c'est ce qui fait la différence entre un pro et un expert.

[Mac LAK]

Je pense qu'il y a une césure énorme entre un pro et un expert.

Pas pour moi. Être pro est, à mon sens, un impératif pour être qualifié d'expert. Je te rappelle que l'antonyme de "professionnel", c'est "amateur"...
Tel que je le vois (et l'ai vécu), un amateur (comprendre "débutant", "stagiaire", "reconverti", etc.) doit être géré, guidé et encadré pour que son travail soit exploitable. Un professionnel, lui, est autonome.

Comment peux-tu considérer qu'un expert doive être encadré, voire tenu par la main, pour rendre son travail utilisable ? Pour moi, c'est un non-sens. A quoi pourrait bien me servir un "expert" qui, même s'il connait toute la tripaille interne de son domaine, n'est pas capable de s'interfacer avec les autres, de travailler en collaboration, ou pire : n'a jamais bossé sur un projet qui pousse son domaine dans ses derniers retranchements ?

Parce que le cœur du problème est là également : en prenant ton exemple de JEE, est-ce que l'on peut considérer réellement comme expert quelqu'un qui n'a jamais réellement déployé une très grosse application dans un environnement réel, et non plus dans un joli bac à sable idéal construit exprès pour ?

Certes, il y a beaucoup de pros qui ne sont pas des experts, c'est un fait (on a tous un collègue dans le collimateur à ce sujet, je pense). Tout comme il y a beaucoup d'amateurs très éclairés. Mais être expert, ce n'est pas ne maîtriser QUE la technique "pure", c'est aussi maîtriser l'UTILISATION et l'INTÉGRATION de ladite technique dans un environnement concret. Et pour ça, être professionnel est un impératif.

[deadalnix]

J'aurais envie de dire, ça dépend expert en quoi.

Un expert, par définition, c'est quelqu'un de très pointu dans son domaine. Il y a des domaines ou l'expérience en entreprise fait beaucoup (mais n'est pas suffisant comme déjà dit). Si l'on parle d'un expert dans une technologie, son déploiement, son développement, alors je ne peut que rejoindre Mac LAK.

Mais cela exclue des personnes que je qualifierais d'expertes. Par exemple, on peut être expert sur des techniques de traitement du signal, de l'intelligence artificielle, etc . . . dans ces domaines, l'expérience et la connaissance priment sur la méthodologie, et peuvent donc être acquise de façon extra professionnelles (bien que, ce soit à mon avis bien plus facile à acquérir de façon professionnelle).

[Chico el guacamole]

il n'y a pas que le exit qui gène. si je ne me trompe pas la façon de compter le nombre d'argument aussi non?

tu marques un point , je l'ai écrit de mémoire et c'est $? et non $*

de toutes manières je trouve que ces langages de scripts 'hiéroglyphiques' ( j'entends par là utilisant des symboles à tout va : ksh, perl, php ) ne me plaise pas. Je préfère quand même des langages plus 'lisible', mais c'est un avis purement subjectif j'en conviens.

par contre je pense que même dans un langage de script, l'utilisation de règles simples de codage et une écriture simple et aéré ( éviter de mettre 50000 instructions en une ligne par exemple ) permet un relecture et une maintenance plus aisée.

Venant au départ du monde PC, je me suis fait depuis 5 ans au monde Linux/unix et j'ai du mal à y revenir, je m'installe sur tous mes postes PC/Windows, la console msys ou les commandes unix pour la console DOS.

je crois que c'est un autre débat, on s'éloigne du sujet , mais ça manque un langage de script simple et efficace multi-plateforme, non ?

[Alain Defrance]

Parce que le cœur du problème est là également : en prenant ton exemple de JEE, est-ce que l'on peut considérer réellement comme expert quelqu'un qui n'a jamais réellement déployé une très grosse application dans un environnement réel, et non plus dans un joli bac à sable idéal construit exprès pour ?

Certes, il y a beaucoup de pros qui ne sont pas des experts, c'est un fait (on a tous un collègue dans le collimateur à ce sujet, je pense). Tout comme il y a beaucoup d'amateurs très éclairés. Mais être expert, ce n'est pas ne maîtriser QUE la technique "pure", c'est aussi maîtriser l'UTILISATION et l'INTÉGRATION de ladite technique dans un environnement concret. Et pour ça, être professionnel est un impératif.

En fait je crois qu'on est d'accord, on a juste du mal à se mettre d'accord sur les termes. Je voulais dire que pour moi pro != expert. Mais l'expérience réel du terrain est une condition nécessaire mais pas suffisante à justifier un niveau d'expertise. Au final on est du même avis

[Mac LAK]

En fait je crois qu'on est d'accord, on a juste du mal à se mettre d'accord sur les termes. Je voulais dire que pour moi pro != expert. Mais l'expérience réel du terrain est une condition nécessaire mais pas suffisante à justifier un niveau d'expertise. Au final on est du même avis

Si, comme ton message le laisse penser, tu veux simplement préciser que tous les pros ne sont pas des experts, mais qu'un expert doit forcément avoir une expérience réelle (donc, selon mes termes, être un professionnel), alors oui, on est bien d'accord en effet.

[stef13_fr]

Bonjour à tous

Il y a 2 ans, sur Lyon, dans une SSII, un jeune embauché qui eu pour mission de récupérer en java une liste d'image jpeg dans un répertoire.
comme il avait brillamment remarqué que les images pouvaient s'écrire avec l'extension jpg ou JPG il a eu l'intelligence de griffoner sur un papier ce qu'il s'apprétait à faire : 'jpg, jpG, jPg, jPG, ....JPG'
construire un tableau pour valider les extensions, mais c'est naze !, même dans un autre langage, on testerait les noms en minuscule.
j'en ri encore.

Je me rappelle que c'est cette même personne qui ne sortait pas des boucles quand il avait trouvé ce qu'il cherchait, ça ça m'énèrve !
par exemple :

Code :

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

1
2
3
4
5
  boolean found=false;
  for ( int i=;i<1000000000000;i++) {
      if (i==3) found=true;
   }

dans une boucle avec plus d'instruction lorsque l'on relit le code on se demande toujours pourquoi

Enfin pour les chefs de projets de notre client principal de l'époque, la politique de création des shells KSH était de ne pas faire de fonctions, de ne pas factoriser le code, je vous laisse imaginer les copier/coller et ce que je pense de cette hérésie

allez comme c'est vous une dernière dans ces scripts KSH :

Code :

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

1
2
3
4
5
6
7
8
9
   if [ $* -ne  2 ]; then
       echo "Nombre de parametres incorrect"
       exit 1
   else
      blablabla
   fi

   blablabla2

j'ai peut-être tort mais le exit et le else me semble redondant, le code 'blablabla' et 'blablabla2' étant toujours éxecuter ensemble

le pire que j'ai fait ?
à mes débuts, une parmi tant d'autres, une fonction de 600 lignes.
et vous ?

le pire que j'ai vu
un programme C en un fichier de 17000 lignes, réductible à 2000 lignes si les règles de factorisation simples avaient été faites et le code mort enlevé.

je rends l'antenne

a tcho

Il faut que tu m'explique un peu quand tu dis "
Enfin pour les chefs de projets de notre client principal de l'époque, la politique de création des shells KSH était de ne pas faire de fonctions, de ne pas factoriser le code"
A mon avis, c'est vraiment anti productif et dans l'esprit complètement abérant. Ce qui m'étonne le plus, c'est que c'est une politique défini par des chefs de projets. Y'a surement quelque chose que j'ai raté. Ils sont payé au Ko ? au nombre de ligne ?
Explique car ça va m'empêcher de dormir

[Jidefix]

Il faut que tu m'explique un peu quand tu dis "
Enfin pour les chefs de projets de notre client principal de l'époque, la politique de création des shells KSH était de ne pas faire de fonctions, de ne pas factoriser le code"
A mon avis, c'est vraiment anti productif et dans l'esprit complètement abérant. Ce qui m'étonne le plus, c'est que c'est une politique défini par des chefs de projets. Y'a surement quelque chose que j'ai raté. Ils sont payé au Ko ? au nombre de ligne ?
Explique car ça va m'empêcher de dormir

A mon avis c'était ironique