Discussion :

[olivier50]

Quand on voit ce qu'est le data management, la pauvreté des articles des magazines sur le machine learning, les spécialistes ont de très beaux jours devant eux car ils sont rares. Le jour où le monde nécessitera des gens vraiment polyvalents et adaptables ce sera la fin des ssiis et on verra le développement du portage salarial: mais les besoins en expertise seront plus grands: sécurité, intelligence artificielle...Les vieilles ssiis qui convertissent des factures en fiche de paie n'auront plus leur place.

[Marco46]

J'ai vu de tout dans ma vie, et j'ai commencé pour la première fois à programmer à l'âge de 12 ans.
Ce que je peux affirmer c'est que si, programmer, ça demande du temps pour s'apprendre,
ce n'est pas parcequ'on lis un tuto qu'on sais developper. Clairement, non.

Tim Cook est un manager, pas un technicien. Au mieux il a été dev junior. Il ne comprend à peu près rien au cœur de métier, un peu comme KilroyFR qui pense comme Laurent Alexandre que développer en 2019 consiste à jouer aux légos peu importe le contexte.

C'est impossible d'avoir une conversation rationnelle avec ce type de personnage c'est comme discuter littérature avec un analphabète. Ils n'ont ni la culture, ni l'expérience qui permettent de discuter de ces sujets.

Si la phrase de Tim Cook est bien traduite (la source n'est pas accessible en Europe, probablement du fait du RGPD) elle est d'une affligeante stupidité. Les mots ont un sens, le terme de maitrise signifie dominer complètement un sujet.

Déjà il sous-entend qu'un étudiant fraîchement diplômé "maitrise" le "codage". Non seulement c'est faux mais le terme de "codage" est tellement vaste qu'il faudrait préciser. Quel type de langage ? Dans quel contexte ? Sur quel type de projet ? Apprendre un langage ne suffit pas à "maitriser" la programmation. C'est en partie pour cette raison qu'il faut beaucoup d'expérience pour "maitriser" ce sujet.

De même ce n'est pas parce qu'une version d'une application est fonctionnelle qu'elle est développée avec maitrise. Le résultat n'est pas le signe de la maitrise, c'est la constance dans le résultat dans la durée et ça ça prend du temps à acquérir et évaluer, c'est vraiment difficile et ne se limite pas à la programmation en terme de compétence.

Ensuite, évidemment qu'une personne douée arrive à être aussi compétente en autodidacte qu'une personne normale via des études. C'est d'une banalité affligeante. C'est vrai dans tous les domaines.

Pour en revenir au dev, c'est un métier fondamentalement artisanal qui nécessite donc énormément de pratique. Un peu comme les médecins qui après des études théoriques ont une partie de leurs études sous forme de pratique en apprentissage (l'internat).

Il manque dans notre métier ce type de système. On s'est satisfait d'un niveau de qualité déplorable au quotidien parce que le métier est jeune et qu'il faut délivrer vite mais c'est un énorme problème. Peu de devs arrivent à un niveau de maturité senior qui peut être qualifié de "maitrise".

[olivier50]

Quand on voit que dans des boites, sous couvert de "best practices" on interdit de coder a += 1 car c'est trop complexe.
Et demain ces mêmes personnes parleront sans complexe prog fonctionnelle, blockchain et peut être quantique. Cependant parler c'est bien, et c'est une chose mais être opérationnel en est une autre.

[Neckara]

Pour en revenir au dev, c'est un métier fondamentalement artisanal qui nécessite donc énormément de pratique. Un peu comme les médecins qui après des études théoriques ont une partie de leurs études sous forme de pratique en apprentissage (l'internat).

Il manque dans notre métier ce type de système.

Tu as des formations informatiques en apprentissages.
En école d'ingénieur, c'est au total ~9 mois de stages, en IUT ~2 mois de souvenir. Cela plus les projets et TPs tout au long de la formation.

Le problème n'est pas tant le manque de pratique qu'on donne le diplôme à à peu près n'importe qui.
Entre une personne qui passe en session 2 avec les 3/4 de ses modules à rattraper, et celui qui sort avec au moins 15 de moyenne, il y a tout un monde.

Le pire, c'est à l'université où tout se compense. Tu ne sais pas coder en C++ ? C'est pas grave, tu sais parler allemand.


Après, on ne peut pas demander à une personne qui sort de 5 ans de formation d'avoir 20 ans d'expérience dans le domaine et on ne va pas demander aux étudiants de faire une formation en 20 années.

[ParseCoder]

C'est l'enseignement de la géométrie qui permet d'apprendre à raisoner et il est scandaleux que la part de la géométrie ai été réduite dans les écoles françaises au profit de la programmation. C'est l'oeuvre de personnes à courte vue qui surfent sur les modes, comme Tim Cook qui lui en plus ne voit que ses intérêt propres.

[Dymmm]

De la part de Tim Cook ce raisonnement est normal. Il gère une boite qui a besoin de dev, il souhaite en avoir pour moins chère donc il va militer pour qu'il y ait un maximum de personnes formées.
Comme indiqué par certaines personnes dans ce sujet, le développement est encore aujourd'hui artisanal. En bon directeur d'industrie il est normal de vouloir appliquer le taylorisme, comme dans toutes les industries de production plus ancienne.
Le futur développeur sera très spécialisé après une courte formation interne, facilement remplaçable et à bas coût.
Ça ce sont des faits que je pense observables.
Après, je vais me laisser un peu extrapoler et dire que la mise en place de tout cela arrive peu à peu. Prise en charge par l'éducation nationnal dès le plus jeune age pour enseigner qu'on est un groupe et non un individu. N'enseigner que les fondamentaux et laisser le reste au écoles privées un peu chère. Peut être plus tard laisser les filières techno aux banlieues et les générales aux villes.... enfin, je suis un peu parano aussi.

[grunk]

Après, on ne peut pas demander à une personne qui sort de 5 ans de formation d'avoir 20 ans d'expérience dans le domaine et on ne va pas demander aux étudiants de faire une formation en 20 années.

En fait jusqu'à y'a pas très longtemps l'informatique et plus particulièrement le développement était un métier exercé à 99% par des passionnés. Donc des personnes qui à la sortie de l'école avaient déjà des expériences importantes du fait de leur projet perso et/ou pro.
J'ai fait une licence pro pour avoir le diplôme j'ai absolument rien appris techniquement et j'étais plus avancé que certains "profs" dans les matières web.

Aujourd’hui les profils changent , a force de rabâcher qu'il y'a une pénurie de développeur et de faire croire qu'on gagner 10K€/mois , pas mal de monde se lance dans une formation dev comme ils auraient fait n'importe quelle autre formation.
Dans les entretiens auquels je participe , je laisse toujours la possibilité aux candidats de me présenter un projet perso. Ça devient rare de trouver quelqu'un qui me présente autre chose qu'un projet fait dans le cadre scolaire et qui me répond autre chose que "c'était imposé" à la question "pourquoi ce choix ?".

[Marco46]

Comme indiqué par certaines personnes dans ce sujet, le développement est encore aujourd'hui artisanal.

Le dev n'est pas "encore" artisanal, le dev est un artisanat. C'est une caractéristique "essentielle", cela ne changera jamais.

Je te renvoie à la littérature afférente :

- No Silver Bullet: Essence and Accidents of Software Engineering, Frederick P. Brooks
- What is Software Design ? ; Jack W. Reeves
- ce que je ne connais pas mais il doit bien y en avoir d'autre ...

En bon directeur d'industrie il est normal de vouloir appliquer le taylorisme, comme dans toutes les industries de production plus ancienne.

C'est logique du point de vue du manager incompétent, mais ça ne fonctionne pas de cette manière. Il n'y a que l'échec en bout de ligne. Le développement logiciel n'est pas une industrie, on ne fabrique pas des objets en série sur la base d'un plan. On écrit le plan c'est à dire le code source.

Le futur développeur sera très spécialisé après une courte formation interne, facilement remplaçable et à bas coût.
Ça ce sont des faits que je pense observables.

C'est voué à l'échec comme les tentatives d'offshorer l'écriture due code en Asie. Ça coute beaucoup plus cher à l'arrivée et c'est de beaucoup moins bonne qualité. Non pas que les devs asiatiques sont forcément moins bons, mais simplement ce n'est pas la bonne organisation du travail pour être efficace.

[GreatDeveloperOnizuka]

Le dev n'est pas "encore" artisanal, le dev est un artisanat. C'est une caractéristique "essentielle", cela ne changera jamais.

Je te renvoie à la littérature afférente :

- No Silver Bullet: Essence and Accidents of Software Engineering, Frederick P. Brooks
- What is Software Design ? ; Jack W. Reeves
- ce que je ne connais pas mais il doit bien y en avoir d'autre ...



C'est logique du point de vue du manager incompétent, mais ça ne fonctionne pas de cette manière. Il n'y a que l'échec en bout de ligne. Le développement logiciel n'est pas une industrie, on ne fabrique pas des objets en série sur la base d'un plan. On écrit le plan c'est à dire le code source.



C'est voué à l'échec comme les tentatives d'offshorer l'écriture due code en Asie. Ça coute beaucoup plus cher à l'arrivée et c'est de beaucoup moins bonne qualité. Non pas que les devs asiatiques sont forcément moins bons, mais simplement ce n'est pas la bonne organisation du travail pour être efficace.

Non faut arrêter avec le côté "artistique" du code et autre bullshit. Le mec pèse des milliards et il en a RAF de la beauté d'un code, il faut de la rentabilité. Le fait qu'il pèse des milliards fait que sa voix sera écoutée par les autres décideurs et pas le barbu fanatisé. Je dis pas que c'est bien, je dis juste c'est ce qui se passe.

Les entreprises ont de plus en plus l'envie de se concentrer sur leur coeur de métier pas sur les jobs annexes. L'informatique, même en étant de nouveau internalisée car stratégique, le décideur en aura toujours RAF de savoir ce qu'il y a sous le capot.

[Marco46]

Non faut arrêter avec le côté "artistique" du code et autre bullshit.

Tu n'as pas compris, je ne parle pas d'art. Je parle du processus de création en opposant fabrication manuelle et fabrication en série.

[super_navide]

Evidemment qu'on peu maîtriser la programmation et être très très bon et ne pas avoir de diplôme.
Un diplôme c'est juste valider des compétences mais ce n'est pas la seule méthode.
L'autre méthode c'est d'avoir des exemples de création personnel et je trouve que c'est un plus quand on a un diplôme.

Si quelqu'un est vraiment compétent, passer un diplôme n'est juste qu'une formalité .... si ce n'est pas le cas c'est qu'il y a un problème ....

Mais quelqu'un qui n'a pas de diplôme est souvent une personne qui veut faire que des chose qu'elle aime bien genre les maths c'est chiant donc je fais pas.
En gros quand on a pas de diplôme il y a surement une compétence qui manque .....
Donc l'idéal c'est un diplôme et une création perso pour montrer qu'on est pas qu'une machine à apprendre et qu'on peut créer des choses et mettre en pratique des connaissances acquise.

[yukihira]

Tout est histoire d'investissement. Si on s'investit suffisamment dans un sujet, on peut aller très loin dans la maîtrise de celui-ci. L'investissement peut-être sous la forme de longues études. Mais il peut aussi se manifester par la passion, la recherche personnelle, la lecture, etc... Il est à noter que plusieurs développeurs "ont codé" leurs projets à succès (commerciaux ou techniques) bien avant la fin de leurs études supérieures (Bill Gates et son compilateur BASIC, Steve Wozniak et son système d'exploitation, Zuckerberg et son Facebook, etc...). Du coup, la maîtrise est l'aboutissement de cet investissement.

Par contre, il y a d'autres personnes qui prétendent avoir cette maîtrise à cause de certaines cases qu'elles ont cochées, parfois, sans grandes convictions (études, certifications, blabla...). C'est là qu'on arrive à certaines situations où on commence à mettre de la hiérarchie pour corroborer ce qu'on se dit à soi-même afin de se donner plus de légitimité (comme certain(e)s formations/diplômes/entreprises/stages qu'on classe inférieur(e)s de facto aux nôtres). D'où cette culture de vouloir tout classer à tout prix: programmeur < développeur < ingénieur < chercheur (etc...), alors qu'en vrai, il y a juste ceux qui savent coder, et ceux qui ne le savent pas. Coder englobe toute la mise en place d'un système fonctionnel: analyse, design, implémentation, test, déploiement, exploitation. Après, dans un monde professionnel industrialisé, on peut mettre le curseur vers la partie qui nous concerne le plus pour augmenter son expertise selon son périmètre d'actions (développeur, testeur, analyste, administrateur, exploitant...).

Je dirai que de manière globale, on n'a pas besoin d'une formation >= 4 ans pour savoir coder. Mais on a besoin de s'investir afin d'y arriver, et la formation supérieure peut bien faire partie de cet investissement.

[foetus]

Si quelqu'un est vraiment compétent, passer un diplôme n'est juste qu'une formalité .... si ce n'est pas le cas c'est qu'il y a un problème ....

Et non, ce n'est pas vrai

Tu peux faire une formation pas trop mal mais entre les cours et les contraintes d'obtention (*) souvent c'est difficile de décrocher un diplôme.

Par exemple :

• j'ai eu un cours d'IA c'était ultra théorique à base de moteur d'inférences et de TP en prolog. On a fait les algos les plus connus (A*, ...) mais en TP écrits
• il y a toujours des cours BAC+5 comme la comptabilité (avec le grand bilan en en long, en large et en travers) ou du droit (période d'essai, statut entreprises, gestion des cas de conflits ...) et ce n'est pas forcément évident
• des cours complétement à côté de la plaque comme une dizaine d'heures d'administration système (avec de l'Active Directory) ou de formation logiciel (style SolidWorks ou Access)
• un projet long terme qui te bouffe un temps énorme ou alors dont le sujet n'est pas terrible avec une soutenance débile.
• des profs qui notent à la tête du client ou alors le gros c^n qui était ultra tatillon et qui te défonçait au moindre truc qui ne lui plaisait pas

Et pour les contraintes, j'ai eu "minimum 12/20 de moyenne générale, minimum 8/ 20 pour chaque module et minimum 650 au TOEIC anglais" : il faut se sortir les doigts du fion si tu veux réussir sans parler de bien choisir (si c'est possible) son binôme/ trinôme/ ...

[GreatDeveloperOnizuka]

Tu n'as pas compris, je ne parle pas d'art. Je parle du processus de création en opposant fabrication manuelle et fabrication en série.

Ben il y a déjà de grosses parties industrialisées et en série (progiciels, CMS, aide du design pattern, etc.). Il reste les "finitions" càd la customization. On est plus ou moins dans le système de ventes de voiture càd du Toyotisme où tu fais une commande à partir d'un modèle de base et que tu fous les options après.

Donc oui l'informatique est industriel également pour bcp de parties et contrairement à l'automobile, il existe une multitude de models (rien n'interdit de dev tout from scatch) mais ça veut pas dire que l'industrialisation n'existe pas en informatique.

[Marco46]

Coder englobe toute la mise en place d'un système fonctionnel: analyse, design, implémentation, test, déploiement, exploitation.

Non, pas du tout du tout d'accord.

Les deux derniers points n'ont rien à voir, et eux ils peuvent (ils doivent même) s'industrialiser.

Le seul point où je suis d'accord c'est que les devs doivent être capables de gérer ces 2 points là aussi.

Après, dans un monde professionnel industrialisé, on peut mettre le curseur vers la partie qui nous concerne le plus pour augmenter son expertise selon son périmètre d'actions (développeur, testeur, analyste, administrateur, exploitant...).

Industrialiser du dev ça ne veut rien dire. Comment veux-tu industrialiser de la conception ? Industrialiser l'écriture d'un livre ? Ça ne veut rien dire. Industrialiser l'impression d'un livre oui mais pas son écriture.

[grunk]

Industrialiser du dev ça ne veut rien dire. Comment veux-tu industrialiser de la conception ? Industrialiser l'écriture d'un livre ? Ça ne veut rien dire. Industrialiser l'impression d'un livre oui mais pas son écriture.

Industrialiser l'écriture du code c'est pas vraiment possible (quoi qu'avec les framework on y tend) , mais quand on parle d'industrialisation du dev on parle surtout de tout ce qui y'a autour amha.
Typiquement la CI/CD c'est de l'industrialisation.
Quand après un merge ca te lance des tests , que ca te créer une release et que ca envoi un mail c'est industrialisé. On enlève tout ce qui n'a pas de réel intérêt pour justement pouvoir se concentrer sur ce qui compte l’algorithmie , le code , l'ui.

[Marco46]

Ben il y a déjà de grosses parties industrialisées et en série (progiciels, CMS, aide du design pattern, etc.). Il reste les "finitions" càd la customization. On est plus ou moins dans le système de ventes de voiture càd du Toyotisme où tu fais une commande à partir d'un modèle de base et que tu fous les options après.

Ce n'est pas du développement.

J'ai rayé design pattern car ils n'ont rien à faire là dedans. Ils s'utilisent dans le cadre d'un dev.

Donc oui l'informatique est industriel également

Non, je t'invite à lire la définition de ce qu'est un procédé industriel en ingénierie. Tu verras que ce n'est pas applicable au logiciel. On parle de la production d'un bien en série. C'est ça la finalité d'un process industriel.

Vouloir écrire du logiciel en série c'est comme vouloir écrire des livres en série, c'est complètement irrationnel.

Je t'invite à lire les liens que j'ai donné plus haut, ils expliquent tout ça bien mieux que moi.

[Marco46]

Industrialiser l'écriture du code c'est pas vraiment possible (quoi qu'avec les framework on y tend) , mais quand on parle d'industrialisation du dev on parle surtout de tout ce qui y'a autour amha.
Typiquement la CI/CD c'est de l'industrialisation.
Quand après un merge ca te lance des tests , que ca te créer une release et que ca envoi un mail c'est industrialisé. On enlève tout ce qui n'a pas de réel intérêt pour justement pouvoir se concentrer sur ce qui compte l’algorithmie , le code , l'ui.

Oui ça oui c'est de l'industrialisation. Mais comme tu le dis ça vient après un merge, donc après l'écriture du code.

[yukihira]

Non, pas du tout du tout d'accord.

Les deux derniers points n'ont rien à voir, et eux ils peuvent (ils doivent même) s'industrialiser.

Le seul point où je suis d'accord c'est que les devs doivent être capables de gérer ces 2 points là aussi.



Industrialiser du dev ça ne veut rien dire. Comment veux-tu industrialiser de la conception ? Industrialiser l'écriture d'un livre ? Ça ne veut rien dire. Industrialiser l'impression d'un livre oui mais pas son écriture.

Un monde industriel signifie qu'on est sur une chaîne de fabrication. C'est à dire qu'on n'a pas une personne qui fait tout (artisanal). Dans le monde aujourd'hui, on a découpé les périmètres, et chacun se concentre sur son champ d'action.
Mon point était que même si on est recadré sur son propre périmètre, on est quand même censé maîtriser toute la chaîne de codage. Là où les gens ont du mal, est qu'ils croient que coder signifie uniquement aligner des lignes de code. Non, coder c'est faire en sorte qu'une problématique (un besoin) soit résolue sinon cela ne sert strictement à rien. Du coup, pour y arriver, il faut analyser le besoin, dessiner et implémenter la solution, la tester, la livrer, et l'exploiter. Je ne comprends pas où tu te dis je m'arrête uniquement à l'implémentation sans le déploiement et l'exploitation. Et tout "bon codeur" est en devoir de maîtriser toute cette chaîne.

[yukihira]

Industrialiser l'écriture du code c'est pas vraiment possible (quoi qu'avec les framework on y tend) , mais quand on parle d'industrialisation du dev on parle surtout de tout ce qui y'a autour amha.
Typiquement la CI/CD c'est de l'industrialisation.
Quand après un merge ca te lance des tests , que ca te créer une release et que ca envoi un mail c'est industrialisé. On enlève tout ce qui n'a pas de réel intérêt pour justement pouvoir se concentrer sur ce qui compte l’algorithmie , le code , l'ui.

Industrialiser peut tout à fait être technique (comme ce que tu as décrit), qu'organisationnel. Le fait qu'il y a une personne qui s'occupe de l'ui, et une autre qui s'occupe du back-end est déjà de l'industrialisation. Plus on a un produit complexe, plus on a une organisation complexe.