Discussion :

[Pierre Fauconnier]

[...]
En fait, je crois que ce qui fait la qualité d'un code source, c'est intemporel, et c'est toujours applicable.

(1) et j'aurai tendance a penser que je vais bien plus vite rattraper son niveau de Vue que lui mon niveau d'algorithme (sens large)

Alors, évidemment, je vais faire "vieux dinosaure", mais je ne peux qu'être d'accord...

C'est comment qu'on plusse plusieurs fois?

[GuillaumeJ]

Après, ca veut pas dire non plus que les jeunes sont forcément moins bons, ou qu'ils n'ont rien à apporter, hein, je précise

[zecreator]

Après, ca veut pas dire non plus que les jeunes sont forcément moins bons, ou qu'ils n'ont rien à apporter, hein, je précise

J'ajouterai que si les jeunes développeurs paraissent souvent meilleurs et plus productifs, c'est qu'ils sont beaucoup aidés par tout un tas d'outils dans leur environnement de dev, qui font un gros % du travail. Outils d'ailleurs souvent développés par des Seniors

Il n'y a pas de dénigrement de ma part, c'est une réalité. Les jeunes profitent de toutes les années de dev passées, de la réflexion sur les méthodes de dev qu'ont eu leurs aînés. Donc, c'est toujours un peu simple de la part d'un Junior de dire : "Je vais plus vite, je fais moins de bugs...". ben oui, mais parce qu'il profite de toute l'expérience passée.

Comme je l'ai souvent remarqué, de mon point de vue de Senior qui a connu le développement C++ sous MS DOS, en mode full text, on demande de moins en moins aux développeurs de... développer, mais plutôt de maintenir l'existant, faire de la reprise de code, du montage de modules. On est dans une ère de production et d'industrialisation du développement, et non plus dans la recherche et la conception.

Du coup, oui, un profil junior, tout droit sorti d'une école d'ingé, encore sous blistter, peut répondre mieux aux besoins de compétitivité et de production des ESN et SSII aujourd'hui. Jusqu'à ce qu'on le trouve trop vieux....

[el_slapper]

J'ajouterai que si les jeunes développeurs paraissent souvent meilleurs et plus productifs, c'est qu'ils sont beaucoup aidés par tout un tas d'outils dans leur environnement de dev, qui font un gros % du travail. Outils d'ailleurs souvent développés par des Seniors

ne fait,ça dépend, les juniors peuvent aller de 1/20 à 20/20, et les seniors aussi. Je peux te trouver des jeunes diplômés déjà meilleurs que toi(mon neuveu est monstrueux, il est sans doute déjà meilleur que moi, et je ne suis pas le dernier venu), et d'autres incapables de faire un fizzbuzz.

Comme je l'ai souvent remarqué, de mon point de vue de Senior qui a connu le développement C++ sous MS DOS, en mode full text, on demande de moins en moins aux développeurs de... développer, mais plutôt de maintenir l'existant, faire de la reprise de code, du montage de modules. On est dans une ère de production et d'industrialisation du développement, et non plus dans la recherche et la conception.

La maintenance ça a toujours fait 70/80% du boulot.

La partie assemblage est plus intéressante, mais celui qui ne sait qu'assembler sans créer sera toujours, à un moment ou un autre, insuffisant. J4ai assez peu utilisé mes compétences en algo pendant les 8 ans ou j'ai fait du COBOL, mais les 3 fois ou j'ai vraiment fait de l'algo complexe, j'ai sauvé le projet que tout le monde croyait perdu. (Bon, ça dit plus de mal de mes prédécesseurs que de bien de moi, hein.....)

Du coup, oui, un profil junior, tout droit sorti d'une école d'ingé, encore sous blistter, peut répondre mieux aux besoins de compétitivité et de production des ESN et SSII aujourd'hui. Jusqu'à ce qu'on le trouve trop vieux....

Ou jusqu'à ce qu'on le mette sur un projet un peu plus exigeant que les autres. Mais ne t'y méprends pas : des seniors qui n'ont pas le niveau, on en trouve aussi.

[Darkzinus]

Mais ne t'y méprends pas : des seniors qui n'ont pas le niveau, on en trouve aussi.

C'est bien de souligner ce point car effectivement l'expérience ne fait pas tout !

[zecreator]

ne fait,ça dépend, les juniors peuvent aller de 1/20 à 20/20, et les seniors aussi. Je peux te trouver des jeunes diplômés déjà meilleurs que toi(mon neuveu est monstrueux, il est sans doute déjà meilleur que moi, et je ne suis pas le dernier venu), et d'autres incapables de faire un fizzbuzz.

Mais ton neveu est meilleur par rapport à quoi ? Etes-vous tous les 2, au même âge sur les mêmes outils/méthodes ? Aviez-vous les mêmes environnements de dev au même age, et aujourd'hui urilisez-vous les mêmes outils et les mêmes méthodes ?

Depuis la nuit des temps, les jeunes profitent directement ou indirectement de l'expérience de leurs aînés. C'est pas une critique, c'est une logique naturelle.

Ton neveu n'est pas meilleur que toi parce qu'il a appris différemment. Il est meilleur que toi, parce qu'il a l'expérience des erreurs de ta génération et qu'il profite de tes corrections.

Tu devais être meilleur que ton oncle en informatique

[Glutinus]

J'ajouterai que si les jeunes développeurs paraissent souvent meilleurs et plus productifs, c'est qu'ils sont beaucoup aidés par tout un tas d'outils dans leur environnement de dev, qui font un gros % du travail. Outils d'ailleurs souvent développés par des Seniors

Il n'y a pas de dénigrement de ma part, c'est une réalité. Les jeunes profitent de toutes les années de dev passées, de la réflexion sur les méthodes de dev qu'ont eu leurs aînés. Donc, c'est toujours un peu simple de la part d'un Junior de dire : "Je vais plus vite, je fais moins de bugs...". ben oui, mais parce qu'il profite de toute l'expérience passée.

Comme je l'ai souvent remarqué, de mon point de vue de Senior qui a connu le développement C++ sous MS DOS, en mode full text, on demande de moins en moins aux développeurs de... développer, mais plutôt de maintenir l'existant, faire de la reprise de code, du montage de modules. On est dans une ère de production et d'industrialisation du développement, et non plus dans la recherche et la conception.

Du coup, oui, un profil junior, tout droit sorti d'une école d'ingé, encore sous blistter, peut répondre mieux aux besoins de compétitivité et de production des ESN et SSII aujourd'hui. Jusqu'à ce qu'on le trouve trop vieux....

J'ai une théorie plus vaseuse.

Les jeunes développeurs sont souvent moins efficaces, mais ils vont aller droit au but. Comme par exemple faire 50 copier-coller. Un développeur plus performant va avoir des idées, de l'expérience, pour avoir une meilleure architecture. Mais à un point donné du projet, il sera moins avancé qu'un jeune développeur, et même deux s'il a une facturation qui leur est double. Sauf qu'à la fin, le coût de maintenance, d'évolution sera minime. Mais ça, un client ne le voit pas, et une SSII n'en a rien à branler puisqu'elle veut placer une TMA de 4 jeunes non-informaticiens formés sur le tas.

Pour avoir vécu la situation ma mission d'avant, et la même actuellement mais poussée à un paroxysme :
* Mon équipe doit faire un datawarehouse, sauf que l'architecte a eu la folie de grandeurs, il a promis un toolkit, qui au final a dû être spécialisé pour chaque traitement. Résultat, on perd énormément de temps à utiliser son architecture alors qu'il y a des éléments parfaitement inutiles (genre insérer des doublons pour après les supprimer). Le moindre changement, le moindre truc provoque une dispute entre moi et mes collègues car on n'a pas du tout la même optique : moi je suis plutôt pour éliminer les tâches débiles, mais ils veulent la garder parce qu'ils veulent pas prendre le temps d'analyser quels seront les impacts...

C'est sûr que le triple de jeunes développeurs pisseurs de code seraient allés bien plus loin - et surtout que moi, j'ai pas encore la carte "convaincre mon chef malgré les éléments factuels", j'ai plutôt un complexe de Cassandre.
Franchement, je serai un CDP, je prendrai un Sopra / Cap Gemini avec un bon Directeur de projets etd dans 6 mois j'aurai eu le projet que je voulais à la bse.

* En parallèle, l'équipe qui s'occupait du Staging, donc la partie de nous fournir les données, eux ont fait les trucs procéduralement, en toute intelligence, avec toute la puissance et l'expérience d'architectes / développeurs. Quand on leur demande "vous pouvez rajouter telle fonctionnalité", ils rigolent car ils l'avaient déjà développé en sous-marin, ils ont à rajouter un =1 dans leur fichier de paramètre global et hop roule ma poule.

[Ekolamar]

Mais ton neveu est meilleur par rapport à quoi ? Etes-vous tous les 2, au même âge sur les mêmes outils/méthodes ? Aviez-vous les mêmes environnements de dev au même age, et aujourd'hui urilisez-vous les mêmes outils et les mêmes méthodes ?

Depuis la nuit des temps, les jeunes profitent directement ou indirectement de l'expérience de leurs aînés. C'est pas une critique, c'est une logique naturelle.

Ton neveu n'est pas meilleur que toi parce qu'il a appris différemment. Il est meilleur que toi, parce qu'il a l'expérience des erreurs de ta génération et qu'il profite de tes corrections.

Tu devais être meilleur que ton oncle en informatique

Non, c'est juste que tout le monde est différent et que nous n'avons pas tous les mêmes capacités, la même volonté d'apprendre ni la même envie.
Sur le principe c'est un peu comme le saint Graal de la Sillicon Valley avec les top ingénieur qui sont 20 fois plus productif que les autres (zut j'ai oublié le nom du principe) : En gros ils veulent les "aspergers" (mot fourre-tout).

Et avec le temps j'en arrive vraiment à cette conclusion : Tout le monde ne se vaut pas.

Après bien sûr cela varie en fonction des domaines, des périodes de l'année ou de l'état d'esprit du moment, mais tu auras toujours des personnes 10-20-30 fois plus productives que d'autres parce qu'elles "pensent" mieux, et ça n'a rien à voir avec l'âge. C'est le "mindset" de la personne, le câblage de son cerveau et sa passion dans ce qu'il fait et d'aller au bout des choses.

[zecreator]

Non, c'est juste que tout le monde est différent et que nous n'avons pas tous les mêmes capacités, la même volonté d'apprendre ni la même envie.
Sur le principe c'est un peu comme le saint Graal de la Sillicon Valley avec les top ingénieur qui sont 20 fois plus productif que les autres (zut j'ai oublié le nom du principe) : En gros ils veulent les "aspergers" (mot fourre-tout).

Et avec le temps j'en arrive vraiment à cette conclusion : Tout le monde ne se vaut pas.

Après bien sûr cela varie en fonction des domaines, des périodes de l'année ou de l'état d'esprit du moment, mais tu auras toujours des personnes 10-20-30 fois plus productives que d'autres parce qu'elles "pensent" mieux, et ça n'a rien à voir avec l'âge. C'est le "mindset" de la personne, le câblage de son cerveau et sa passion dans ce qu'il fait et d'aller au bout des choses.

Ce que je dis, c'est que la productivité est accelerée par le fait qu'aujourd'hui les développeurs ont des outils plus performant. En une ligne de commande, on peut créer une structure de site Web prête à l'emploi. Avec Doctrine par exemple, on fait de moins en moins de SQL. Y a beaucoup d'automatisation. Le job est plus fiable, et on perd moins de temps sur de la configuration.

Y a 20 ans, tout ça n'existait pas ou peu.

[Pierre Fauconnier]

[...]En une ligne de commande, on peut créer une structure de site Web prête à l'emploi. Avec Doctrine par exemple, on fait de moins en moins de SQL. Y a beaucoup d'automatisation.[...]

Le problème pour le "développeur", le vrai, c'est qu'il est de moins en moins "développeur". Je discutais il y a quelques jours avec un "développeur" Web qui, en fait, clique sur Suivant pour installer WP chez ses clients, puis coche et réarrange quelques addins. Mais il se présente très sérieusement comme développeur web.

[...][...]Avec Doctrine par exemple, on fait de moins en moins de SQL[...]

J'ai moi-même proposé dans un billet de blog une manière d'interroger Access au départ d'Excel sans faire du sql (déporté sur access) et de l'adodb, en installant (peut-être même sans trop y comprendre grand-chose), quelques procédures très simples. Je pense que cette direction qui est prise est irrémédiable et fait partie de l'évolution normale des choses. Dans bien d'autres domaines, depuis l'ère industrielle, nous avons amélioré, standardisé les processus, limitant le travail d'un nombre de plus en plus grand de personnes à "un respect et une application des procédures"... En tirant un peu, nos "design pattern" ne sont rien d'autre.

A l'avenir, nous allons avoir de plus en plus besoin d'intégrateurs, d'assembleurs de briques logicielles, et de moins en moins de "vrais" développeurs. Est-ce un bien ou un mal, je n'en sais trop rien. Dans une vie antérieure, j'ai été apprenti boulanger. J'ai bien appris mon métier car j'avais un gars super top comme maître d'apprentissage, mais certains copains de l'époque, appelés eux aussi boulangers, étaient en fait des mélangeurs de poudres préparées. Comme quoi, il n'y a pas qu'en informatique.

Je crois cependant qu'il y aura des niches pour des "orfèvres" du code.

[Invité]

Ce que je dis, c'est que la productivité est accelerée par le fait qu'aujourd'hui les développeurs ont des outils plus performant. En une ligne de commande, on peut créer une structure de site Web prête à l'emploi. Avec Doctrine par exemple, on fait de moins en moins de SQL. Y a beaucoup d'automatisation. Le job est plus fiable, et on perd moins de temps sur de la configuration.

Ouais et avec des requêtes bien dégueulasses générées automatiquement, ma job est assurée pour quelques décennies encore

[zecreator]

Ouais et avec des requêtes bien dégueulasses générées automatiquement, ma job est assurée pour quelques décennies encore

Dégueulasses je ne sais pas. Ces outils répondent surtout à une majorité de besoins en entreprise. A part sur de l'exploitation de type Big Data ou Finance, y a pas vraiment besoin de créer des requêtes SQL sur mesures. Les requêtes de base générées par Doctrine ou Hibernate suffisent largement.

[el_slapper]

Dégueulasses je ne sais pas. Ces outils répondent surtout à une majorité de besoins en entreprise. A part sur de l'exploitation de type Big Data ou Finance, y a pas vraiment besoin de créer des requêtes SQL sur mesures. Les requêtes de base générées par Doctrine ou Hibernate suffisent largement.

Sauf que le besoin en big data explose. Et, à une toute autre échelle que les anciens, on se retrouve de plus en plus avec les mêmes problèmes que les anciens.

Le souci, c'est qu'entre un gnou qui ne sait pas faire une requête SQL sans générateur, et un expert qui va la peaufiner au millimètre, le recruteur ne sait pas faire la différence. Et il va mettre tout le monde dans le même paquet.

[Darkzinus]

Ouais et avec des requêtes bien dégueulasses générées automatiquement, ma job est assurée pour quelques décennies encore

On en voit aussi des bien dégueulasses écrites à la main … Donc effectivement tu ne risques pas le chômage !

[tesla]

Sauf que le besoin en big data explose. Et, à une toute autre échelle que les anciens, on se retrouve de plus en plus avec les mêmes problèmes que les anciens.

Le souci, c'est qu'entre un gnou qui ne sait pas faire une requête SQL sans générateur, et un expert qui va la peaufiner au millimètre, le recruteur ne sait pas faire la différence. Et il va mettre tout le monde dans le même paquet.

Sans faire du Big Data ou de la finance, le code SQL généré ça fait mal au coeur. Même sans être un puriste.
On ne fait que déplacer le problème en fait.

Là ou il fallait un serveur basique simple processeur avec 1 Go de mémoire pour faire tourner une appli. On se retrouve avec un serveur quad core 16 Go de mémoire pour faire tourner la même appli. Pourquoi ? Ah ben l'appli embarque maintenant 5 ou 6 frameworks exotiques, dont Hibernate qui bouffe la moitié de la mémoire à lui tout seul ("on monte toutes les datas en mémoire, c'est plus rapide tu vois"). C'est une approche, disons....différente.

[Pierre Fauconnier]

[...]Ah ben l'appli embarque maintenant 5 ou 6 frameworks exotiques, dont Hibernate qui bouffe la moitié de la mémoire à lui tout seul ("on monte toutes les datas en mémoire, c'est plus rapide tu vois").[...]

Ca me rappelle deux trois trucs:
Un "prof" qui nous "expliquait" la création d'une appli web en asp.net... "Tu cliques sur suviant,... suivant,... suivant..." Tu vois, ça t'a créé ton "Entity framework" tout seul, ton appli est prête...

Oui mais, m'sieur, chez moi ça marche pô..... Ben supprime et recommence (arf, c'est juste qu'entretemps, on a renommé le champ d'une table avec une majuscule... Merde, faut tout refaire depuis le début)... On avait un prof "mélangeur de poudre" qui croyait qu'il pouvait enseigner parce qu'il savait cliquer sur "suivant"...

On utilise des frameworks sans savoir sur quoi ça s'appuie derrière. On a aujourd'hui des "développeurs" qui créent des applis par quelques clics (web, style wordpress ou autre, ou "dot.net" par quelques clics également qui créent une "appli" standard et merdique en pissant des milliers de lignes de code dont le "développeur" ne comprend rien, ...) et on se dit "développeur"...

je n'ai rien contre les frameworks, quels qu'ils soient, mais je pense qu'il est intéressant de connaître ce qu'il y a derrière, car sans ça, on n'est pas développeur, mais assembleur de briques logicielles.

[el_slapper]

(.../...)je n'ai rien contre les frameworks, quels qu'ils soient, mais je pense qu'il est intéressant de connaître ce qu'il y a derrière, car sans ça, on n'est pas développeur, mais assembleur de briques logicielles.

Certaines boites conçoivent délibérément leurs architectures applicatives pour pouvoir utiliser ce genre de profils. Ils ont un noyau de vrais bons qui font les choses compliquées, et toute une armada de gens qui se contente de faire du copier coller et de l’assemblage de micro-services. Ca marche moins mal que je ne le craignais, mais le jour ou il faut faire un micro-service un peu moins basique que les autres, on est tributaire des rares architectes. C'est un déplacement du risque, et je reste peu convaincu sur le long terme.

[Jean-Philippe André]

J'ai vécu cette frustration du clic, en cours de MVC, que j'avais demandé, car j'étais en capacité de reprendre un projet en cours, mais pas de savoir dans quel ordre en créer un nouveau...
J'ai donc suivi un cours, et des la premiere heure, j'ai compris qu'en fait c'est Visual Studio qui te fait tout le boulot avec des clics droits et des Vues faites à la volée

C'est tout fait pour faciliter notre travail, mais pour ceux qui comme moi aiment avoir l'info du comment du pourquoi, ca court-circuite, et on est forcé d'admettre que ca se fait comme ceci ou comme cela

[foetus]

Certaines boites conçoivent délibérément leurs architectures applicatives pour pouvoir utiliser ce genre de profils

Pour certaines société qui font des jeux vidéos (ou peut-être des simulations) c'est essentiel
Cela s'appelle "data-driven programming". C'est essentiel, parce que le "game designer", le modeleur, ... peuvent tester tout de suite son travail avec le moteur de rendu.

[Mat.M]

Sur le principe c'est un peu comme le saint Graal de la Sillicon Valley avec les top ingénieur qui sont 20 fois plus productif que les autres (zut j'ai oublié le nom du principe) :

n'est-ce pas le principe de Pareto ?