Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?

Il s'agit en fait d'un débât en deux parties.

La première peut se résumer à cette question sur programmers.stackexchange.com. Le développeur qui pose la question semble surpris de constater que l'essentiel de son métier n'est pas le développement de nouveaux logiciels mais plutôt la maintenance de logiciels existants. Il évalue même le rapport entre les deux à 90%/10%.
La première question est donc : pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants ?
Personnellement je pense que, sans atteindre une proportion de 90/10, la maintenance constitue l'essentiel du métier: on doit modifier des logiciels existants et concevoir de nouveaux logiciels en pensant à leur maintenabilité.

La deuxième - la question principale - est donc la suivante : Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ? J'inclus dans cette question à la fois le métier de développeur (analyste/développeur...) et celui d'ingénieur d'étude et de développement, dont les responsabilités en matière d'architecture logicielle sont supérieures.

Je ne dirais pas où j'ai fait mes études car je sais que les programmes ont pas mal changé là-bas depuis et je ne veux pas faire de mauvaise pub, mais pour ma part je n'ai pas été formé correctement à la réalisation de logiciels dans un milieu professionnel. En particulier je n'ai reçu aucune formation en ce qui concerne la maintenabilité. Jamais je n'ai appris à concevoir une application avec pour objectif de la rendre maintenable dans le cadre de mes études. Je trouve cela d'autant plus surprenant que la littérature sur le sujet existe depuis les années 90', je pense notamment à Robert C. Martin. En fait, pour caricaturer, j'ai plus l'impression que l'on forme plus les étudiants à créer des applications "de loisir" que des applications professionnelles.

Une petite idée pour conclure: en stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?

Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!

Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.

Citation:

---

Envoyé par sevyc64

il leur ait plus enseigner tout ce qui est analyse, conception

---

Un problème que j'ai coutume de relever lorsque je discute du sujet : que ce soit sur le Web, dans les livres ou en cours, les notions telles que les design patterns sont presque toujours enseignés à l'envers.
Un cours de conception objet pourrait par exemple débuter par : "Le cours d'aujourd'hui sera consacré au pattern Stratégie. Le pattern Stratégie consiste..." En revanche le cours ne commencera pratiquement jamais par "Reprenons l'exemple de la semaine dernière: nous voulons ajouter un nouveau moyen de faire blabla, qui pourrait être utilisé par la classe X à la place de la classe Y. Pour l'instant la classe X instancie un Y dans son constructeur..."

En tout cas peut-être un élément de réponse à:

Citation:

---

Envoyé par sevyc64

ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.

---

avec lequel je suis entièrement d'accord.

Les rapports classiques sont entre 70/30 et 80/20 pour de la maintenance. Un lien présent sur la discussion de stack est à 64/36.

Après, la distinction n'est pas toujours évidente. En 2008, j'ai été amené à refondre un existant de 1972(une génération d'impressions à destination des clients). Dans le même langage. Par bien des aspects, c'était du projet : nouveau code, nouveau formats de fichiers, nouvelle sortie pour l'impression..... mais aussi de la maintenance préventive : en remettant le code dans un ordre logique(après 36 ans de maintenance, ça bavait de partout, et les mêmes données étaient modifiées bien des fois tout au long du traitement), en corrigeant au passage certains bugs que personne n'avait jamais detecté, en refactorisant les algorithmes, et tout simplement en s'insérant "en douceur" dans les chaines existantes, au même endroit que les anciennes.

Suivant comment on compte, on arrivera à 60% ou 90%. Mais on travaille majoritairement sur ce qui marche.


Pour ce qui est de la formation, c'est pareil partout. J'ai fait une formation d'ingénieur plasturgiste, et nous étions bien mieux préparés à la R&D qu'à la production, qui constituait une part non négligeable des emplois. Mais peut-être était-ce quand même mieux identifié qu'en informatique. Nous savions qu'il fallait des ingénieurs de production, bien avant d'être diplômés.

Pour ce qui est des capacités des codeurs frais sortis des écoles, j'en sais rien. Je fais surtout du cobol, et on a assez peu de jeunots.....

Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:

Citation:

---

Je fais surtout du cobol, et on a assez peu de jeunots...

---

Personnellement je n'ai jamais vu de carte perforée pour de vrai ;)

Citation:

---

Envoyé par mattj

Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:

---

En même temps, MicroFocus a tendance à en rajouter(pour des raisons marketing évidentes). Cobol, c'est une niche, y'en a, et y'a des gens qui savent faire. Pas besoin de milliards de jeunots, parfois y'en a un qui se forme sur le tas, et ça suffit(à mon grand regret, j'aimerais être une ressource rare, donc chère).

Citation:

---

Envoyé par mattj

Personnellement je n'ai jamais vu de carte perforée pour de vrai ;)

---

Moi non plus. Mon père non plus(et il a commençé en 72).

Citation:

---

Envoyé par mattj

Pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants?

---

Citation:

---

Envoyé par sevyc64

Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!

---

@sevyc64 : Je ne suis pas d'accord avec ta "séparation", très française.. Ce n'est pas parce qu'on reste longtemps dans la même boîte que l'on fait plus de maintenance..

Cela dépend du domaine, principalement.. et du profil de qui on parle...

Il est relativement évident que dans la fabrication de sites Web et d'applis mobiles ou web, on fait plus de dev que de maintenance...

Par contre (et là à mon avis il y a effectivement une énorme lacune de connaissances, de prise de conscience et de formation, que ce soit pour les jeunes diplômés ou les profs) dans une grande majorité de domaines industriels la maintenance est le coeur, pour la simple raison de la durée de vie et du coût de développement de la plupart des logiciels..

Outre les héritages (de Fortran , Cobol, C, Prolog, Pascal, Delphi, VB, Motif, ou Forms et autres GKS) de "vieux" outils fonctionnant parfaitement, et représentant non seulement une masse de code considérable mais également une connaissance et un débuggage souvent à toute épreuve (à l'époque c'était souvent des gens du métier qui développaient, et il y a souvent plus de 30 ans de débuggage), même les nouveaux doivent répondre à des impératifs de durée de vie longue... Et souvent même les sites / applis Web...

De ce que je vois des formations et des devs présentés ici (sans même compter les sites où on clique et où on voit que ce n'est pas mis à jour depuis 5 ans...), il y a effectivement une lacune profonde en ce qui concerne la maintenabilité et le fait de prendre en compte le futur, et je ne parle pas du futur à 2 ans....

Mais tout ceci, et je l'ai déjà dit ailleurs, provient à mon avis essentiellement et de l'engouement des jeunes vers l'info dû aux jeux et au contact très tôt avec la progammation, et à l'engouement (indû) des moins jeunes pour l'info et de la culture de l'enfant-roi où tous ces jeunes sont des "petits génies" en puissance, et la "créativité" est la source de tout...

Moi qui suis maintenant un "vieux", je savais dès 1982 que les formations en info étaient juste le remplacement des formations de "secrétaires", et q'on allait former des générations d'"ouvriers" , pas manuels mais intellectuels..

Tout ce que vous notez provient de celà : à la base 3 illusions :

• une illusion d'abord que "tout ce qui et nouveau est bien et tout ce qui est ancien est obsolète"
• une illusion ensuite que "n'importe qui avec de la créativité peut devenir Steve Jobs ou Bill Gates"
• et enfin une illusion que "n'importe qui avec de la créativité pourra trouver un boulot lui correspondant".

ça se saurait si tout le monde pouvait être architecte ou compositeur... ou même si n'importe quel musicien pouvait être compositeur... ça se saurait si n'importe quel physicien pouvait avoir un Prix Nobel ou avoir une équation à son nom... ça se saurait si n'importe quel mathématicien pouvait laisser un théorème... Pourquoi l'informatique serait-elle différente ???

Ce qui a été mal transmis et mal assimilé est que, dans l'info comme en musique, la majorité des "instrumentistes" jouent les oeuvres de quelques autres...

La prise en compte de ça débouche immédiatement sur la notion de maintenabilité....

De plus, l'engouement et l'enseignement de langages plus ou moins ésotériques ou de "dernière" génération propae cette idée qu'il n'y a pas à penser au passé (et donc au futur)... (voir plus bas...)

Citation:

---

Envoyé par mattj

Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel?

---

Citation:

---

Envoyé par sevyc64

Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.

---

Je ne travaille que peu avec des jeunes, mais il suffit de voir ici, que ce soit sur les forums techniques ou sur ce forum, à propos des debuggers et autres, ou de la lisibilité du code..

Quant à la conception, il suffit de regarder un peu le forum Conception ou Architecture pour s'apercevoir que le bon sens et la logique sont (souvent) écrasés par l'application de modèles / patterns pré-définis...

Quant à la doc, n'en parlons pas... Entre le "tout javadoc" et le "rien"...

Citation:

---

Envoyé par mattj

Personnellement je n'ai jamais vu de carte perforée pour de vrai ;)

---

Moi si :P Le sujet de thèse d'une de mes collègues à l'époque était la traduction d'un programme scientifique de cartes perforées en programme "fichier".. Et c'était en 1982 ...

Citation:

---

Envoyé par sevyc64

Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.

---

Les écoles d'informatique comportent il est vrai pas mal d'enseignements pour le jour où la technique et le codage sont abandonnés (management, gestion de projets, etc.). J'y étais encore il n'y a pas si longtemps.

Citation:

---

Envoyé par sevyc64

Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.

---

Ca s'apprend en école mais après je pense que la mise en place des bonnes pratiques dépend des personnes. C'est là que ce fait la différence entre les développeurs qui font les choses et celles qui les font bien.

Citation:

---

Envoyé par sevyc64

Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.

---

Un gros, que dis-je un énorme +1. Mon apprentissage des débuggeurs se limite officiellement au verso d'une feuille de TP expliquant comment fonctionne GDB dans les grandes lignes (et GDB était loin d'être le point central de ce TP). Pour le reste, c'est un cour de bonnes pratiques si tu choisis la filière orientée développement. Autant dire que c'est succint.

Je viens de valider ma L3 Informatique et je continue en master, donc point de vue étudiant.

On a très peu de cours de conception (Et encore, on a à peine vu le pattern MVC), aucun de gestion de projet, et pas énormément de programmation. Au delà des cours, on a aucune information sur les métiers ou retours de professionnels. Pas de stage non plus hormis stage de fin d'étude. Donc en effet je ne pense pas être bien préparé et informé aux métiers du développement logiciel qui est pourtant ceux qui m'intéressent.

Concernant le code, on a différents projets à réaliser mais on a aucun retour, on nous communique juste notre note (Et encore...). Avoir un avis sur le projet est déjà compliqué, alors avoir un avis sur le code est impossible. C'est vraiment dommage car on a besoin d'aide extérieure pour améliorer son code.

Au final je trouve le programme de mon université peu adaptée, c'est d'autant plus bête que c'est une fac bien cotée. C'est vraiment dommage.

Pendant mes études il y a quelque chose qui m'a vraiment choqué, en BTS tous nos profs avait une expérience professionnelle en informatique, donc ont étaient vraiment sensibilisés à ces problématiques, pour la maintenance on a même eu un projet "fil rouge" qui à duré sur 2 ou 3 mois.
Mais après je suis arrivé en L3, et là j'ai vu que la plupart des profs n'avais jamais travaillé de leur vie, ne faisaient que du travail théorique ou des prototypes, et surtout : n'apprenait pas à développer (ne savant pas réellement le faire eux-mêmes). Ça m'a complètement dégouté des cours, le fait que l'on sait que l'on apprend pas grand-chose d'utile et surtout "choqué" de voir des futurs ingénieurs avoir un niveau aussi bas (c'est pas de leur faute, c'est juste les universités qui recrutent n'importe qui comme prof sans regarder les CV), et j'espère vraiment que toutes les universités ne sont pas comme celle où j'ai été.

Les études d'informatique que j'ai pu faire on pour la plus part du temps été mal adaptée au monde professionnel.

j'avais par exemple énormément de conception. UML , merise , et on ne pouvait pas faire une ligne de code sans une étude complète. Certes très formateur mais je n'ai depuis jamais eu le temps de le faire réellement (un petit diagramme sur un coin de post it dans le meilleure des cas).
Parce que entre avoir une conception au poil ou avoir une jolie interface rapidement , le client à vite fait son choix.

En ce qui concerne la maintenance , c'est un peu le cycle infernal. Etudiants pas formés , donc projet galère à maintenir , ces étudiants non formé ne feront sans doute jamais l'effort de coder en vue de la maintenance et donc ne transmettrons jamais cette expérience à d'éventuels stagiaires.

Après il y'a aussi la réalité du terrain. Les timelines et les directions non technique te force parfois (hélas) à faire un boulot dégueulasse ...

Citation:

---

... En stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?

---

Je suis totalement d'accord avec ta proposition !
Un de mes projets de seconde année d'école d'ingénieur a été de réaliser en trois mois un mini DPI (Dossier Patient Informatisé, utilisé dans les hôpitaux).

S'il est vrai que les trois profs suivant les projets pouvaient difficilement passer en revu tout le code de la demi-douzaine de groupes, la note finale reposaient principalement sur "la gestion du projet" ; çàd avoir rempli ce qu'on avait mis dans le cahier des charges initial.

L'argument principal étant : "Les trois-quarts d'entre vous passeront chefs de projet dans 3-4 ans" ... et en attendant on fait quoi ?! Et si on veut rester en R&D ?!

Et j'ai l'impression que c'est pareil pour beaucoup d'écoles d'ingénieurs qui proposent une formation dans le domaine informatique.
Certes, savoir discerner le besoin du désir du client, concevoir un cahier des charges fonctionnelles et techniques, ça aide à ne pas coder quelque chose qui ne sera jamais utilisé. Mais si la fonctionnalité requiert 10 requêtes en base alors qu'une seule pourrait suffire, il vaut presque mieux que la fonctionnalité n'eut pas existé ...

Donc en attendant, j'ai appris seul, et ce n'est pas toujours le meilleur moyen de procéder.

Ce qu'il manque dans l'enseignement à l'université, ce sont toutes les méthodes de développement de qualité. Test unitaires, Refactoring, nommage correct des classes/méthodes/variables, indentation correct du code (oh purée ça... ne jamais prendre un stagiaire sans CheckStyle!), DRY, principes et mise en place d'une intégration continue, procédures/scripts de déploiement automatisés (devops), gestion des versions logicielles ...


Pour se dégager de ses responsabilités, l'enseignement évoque la sacro-sainte séparation entre enseignement et monde du travail : "On vous enseigne les bases, le reste vous l'apprendrez en entreprise !".
Ou encore "On vous enseigne les additions, et pour les multiplications vous les verrez en entreprise".

Bonjour

Un petit avis qui vaut ce qu'il vaut mais qui confortera les opinions déjà décrites.
Où plutôt un exemple.
J'ai été recruté il y a un 18 mois dans une boîte sur un existant: grosse base de données avec des procédures stockées kilométriques et site en PHP.
La philosophie de la cheffe de projet était: aucun check n'est fait car on travaille avec des gens sérieux.
Ben voyons !

Aujourd'hui, je dois faire le support de cette m.... sans nom développée par des jeunes. Je précise que dans cette équipe, je suis le plus âgé. J'ai été consultant auparavant et quand je remettais un projet en production, il était testé, code des unit tests à l'appui et validé par milestones avec le client.
Ce machin a été développé avec certitude que ça marcherait parce que:
1) les utilisateurs sont gentils et sérieux et ne font aucune erreur (humains + robots, les robots, j'ai confiance, les humains, moins).
2) on est des bêtes en PL/SQL donc le support sera vite fait bien fait.

Vous comprenez pourquoi je regarde ailleurs.
Au passage, je précise que j'ai formé des stagiaires à ma logique de qualité du temps où j'étais consultant et je suis fier de leur accomplissement. Je suis pour que les jeunes mettent les mains dans le cambouis et aillent au bout de leurs idées. Mais il faut un encadrement ! Si le management est incapable de baliser le chemin, vous pouvez être sûr que le projet sera bien piètre.

@++

Citation:

---

Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ?

---

Certainement pas les universités ...

Les écoles françaises non plus :roll:

C'est une question d'adaptabilité, en général il faut un voire plusieurs mois, mais, oui, le métier de développeur est autant composé de maintenance de logiciels existants (voir d'améliorations), que de création de logiciels (du moins, c'est ma vision des choses depuis que je suis dans ma boîte).

Personnellement, à part pour de petits projets peut-être, je ne vois pas vraiment de différence entre développement et maintenance. Lorsqu'on travaille sur des applications dont les versions successives s'étendent sur plusieurs années, une nouvelle version contient du nouveau développement et des améliorations de fonctionnalités existantes, on peut donc voir le travail comme du développement ou de la maintenance. Et même lorsque le projet n'est pas très grand, en utilisant une méthode agile, une partie du travaille consiste en la refactorisation du code existant ce qui peut être vu comme de la maintenance. Dans un cas comme dans l'autre, on a un projet avec un début connu, une fin qui devrait l'être et entre deux on fait de la conception et de la programmation.

Comme j'ai également travaillé dans une équipe de support de 3ème niveau chargée de la gestion des problèmes, là le travail est un peu différent; il s'agit de rechercher les causes des problèmes et soumettre des propositions de solutions aux équipes de développement, mais il ne s'agit pas de maintenance non plus

Mon baggage universitaire (jusqu'au master) m'a donné tous les outils dont j'ai besoin, des tests unitaires en passant par UML, conventions de nommage, code DRY, différents langages de modélisation, différents langages de développement...

La seule chose à laquelle je n'étais pas pret était le code qui n'avait pas de tests automatisé, pas de modèle conceptuel écrit, pas de documentation, super copié collé, pas MVC avec des fonctions de plus de 1000 lignes. :ccool: Enfin bon, je profite des maintenances pour rendre le code plus maintenable quand je modifie pas mal de choses à meme endroits.

Comme toujours on trouve de bon sujet sur Développez :P

Je me sens concerné par le sujet puisque je rentre en 5ème année et je commence à toucher au bout de mes études, ou plutôt leur commencement.

Je pense que l'informatique est bien trop vaste pour aborder tous les sujets durant ses études. Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc

On est dans un domaine où nous sommes en formation continu et où les pratiquent des professionnels sont aussi nombreuses que le les lignes de code d'un projet.

Si je regarde aujourd'hui, je sais que je maitrise seulement les bases de Visual Studio même si je suis bien conscient de l'étendue des possibilités offertes. Pourtant, je ne les verrais surement jamais sauf si un projet m'amène à m'y intéresser. C'est tellement vaste que prendre un bout arbitrairement pour commencer peut amener à rater l'essentiel.

A mes yeux, le métier de développeur est difficilement enseignable et oblige à faire des choix restrictif sur ce qui est enseigné. Du coup on se retrouve forcement avec des désaveux lors de notre entrée sur le marché du travail. Il nous manque toujours LA techno que l'entreprise recherche (parmi les 15/20 citées dans l'annonce, évidement).

Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?

Edit : quand je parle de techno, j'englobe aussi les outils ... dedans ^^ C'est les techno au sens large du thème.

Citation:

---

Envoyé par LordMacharius

Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?

---

Par justement ne pas enseigner des choses pointues, mais des choses génériques, une manière de penser, d'analyser, un esprit critique, et surtout du bon sens et de la logique...

Dans les autres domaines que l'info, un ingénieur est à peu près équivalent à un Docteur parce que on sait qu'il n'est pas opérationnel, mais on sait qu'il peut apprendre à l'être en 6 mois.

Parce qu'on lui a enseigné une manière de réfléchir, plus les bases.

Vouloir faire des gens "immédiatement sur le marché" est la clé de l'échec, car les technos bougent... Alors que le fond reste...

Culture générale et des concepts de base plutôt que telle ou telle méthodo, tel ou tel langage...

D'où la remarque par rapport au debugger : ne pas savoir se servir de tel ou tel outil, ça s'apprend suivant l'outil... Raisonner pour débugger, c'est de la logique et de l'analyse, quel que soit l'outil (ou sans).

Citation:

---

Envoyé par LordMacharius

Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc ?

---

Ca ne sert strictement à rien de former une personne sur telle ou telle technologie car les technologies évoluent. Ce qu'il faut en revanche, c'est pouvoir analyser, comprendre le fonctionnement d'une nouvelle technologie, apprendre à se la réapproprier pour ensuite apprendre les mécaniques de la programmation et réutiliser cette technologie.

Voilà pourquoi le métier est intéressant, on ne fera pas la même chose toute notre vie. Et je plains ceux qui ne se tiennent pas à jour et qui seront dépassés dans 2 ans ...