mathieui’s blog : Apprendre aux gens à travailler (et ensemble)

Les langages

Premièrement, il manque une vraie connaissance (non-exhaustive malgré tout) des langages qui sont utilisés. À l’heure actuelle, de ce que j’en ai vu, on lance les langages aux étudiants en leur disant « il faut faire ça, comme ça ». Ça incite les étudiants à ne comprendre ce qu’ils font (une sorte de cargo cult), à bâcler le travail parce ce qu’ils ne comprennent pas, et à ne pas aimer en général les langages qui leur sont donnés ainsi.

Je ne dis pas qu’il faut introduire les étudiants à toutes les subtilités syntaxiques du C++, aux méandres du GC de java, ou encore aux détails du GIL de python, mais simplement qu’il faudrait que les élèves comprennent un minimum ce qu’ils font. Par exemple, pendant mon DUT, on a eu une série de TP portant sur python, qui en réalité n’étaient qu’un prétexte pour l’apprentissage des sémaphores. Très bien ; sauf que, voilà, c’était « bon alors on va travailler sur la synchronisation, et on va utiliser python, débrouillez-vous, je veux le TP dans ma boîte mail avant vendredi 23h59 ». C’est sûr, ça permet de mettre « Python » sur le CV, mais dans la réalité, ça ne passera jamais la première question la plus basique d’un entretien d’embauche.

Le seul langage vu à peu près en détail est je pense java, et encore. Étant donné qu’il faut utiliser des IDE éléphantesques pour arriver à ses fins dans un programme un minimum complexe, je doute que beaucoup connaissent le nom des classes indispensables et leurs variantes (comme ArrayList et Vector, ou HashMap), sans parler des détails d’autoboxing, ellipses et autres joyeusetés.

Mon ressenti le plus flagrant est la phrase d’un enseignant qui, quand on lui a dit que les TP en assembleur, c’était quand même passablement fatiguant : « J’aurais bien fait les TP en C, mais vu votre code, j’ai préféré vous les faire en ASM ». Le seul hic, là-dedans, c’est que jamais, dans le cursus, il n’y a eu de créneau véritablement dédié au C, et à l’écriture de code correct en particulier. Il y a bien eu des TP contenant du C, avec une petite introduction et quelques broutilles ; mais la partie la plus complexe consistait en une liste chaînée (voire doublement chaînée), le gros du travail consistant à écrire un petit programme qui lit un filesystem virtuel.

Après ces modules, on a des enseignants qui considèrent ces notions comme acquises, et qui mettent donc des bouts de code de linux à analyser en partiel. Je trouve ça très bien, mais il aurait été peut-être judicieux que les gens aient été familiarisés avec du code avant.

De la même façon, l’apprentisage d’OCaml, bien que plutôt clair, a laissé de côté un certain nombre de choses, plus ou moins importantes, telles que le fait que le toplevel est une horreur sans nom avec des bugs en plus par rapport à ocamlc, les objets, des détails sur les records qui sont durs à deviner, une partie de la syntaxe qui nous a été dictée plutôt qu’expliquée (ce qui fait qu’il faut réapprendre par-derrière). Ça a quand même laissé une majorité des étudiants avec un ressenti très négatif du langage (qui vient aussi du fait que le « projet » nous faisait utiliser la bibliothèque graphique incluse dans OCaml, qui est « limitée », pour rester poli). Le second projet nous faisait utiliser camlp4, qui n’est là non plus pas vraiment le meilleur exemple de bibliothèque OCaml.

Les outils

De la même façon, je pense qu’on n’apprend pas véritablement aux gens à utiliser des outils pratiques.

Quand 70% des étudiants (80% si on ne ne compte pas ceux qui ont fait BTS/DUT avant) n’ont jamais utilisé de système de gestion de versions (et en les prenant tous en compte, pas que les corrects), ça fait se poser un certain nombre de questions. Parce que je ne parle pas de lire en long, en large, et en travers ce document, même si ça ne peut pas faire de mal, mais utiliser dropbox pour partager du code, à Bac+4 en informatique, c’est quand même plutôt dommage.

C’est d’autant plus dommage que la majorité de ces personnes devront travailler en équipe, et donc nécéssairemeent avec un système de versionnage de code, c’est pourquoi je ne comprends vraiment pas pourquoi il n’y a jamais eu de point fait là-dessus au cours de la formation (N.B. : j’ai eu un cours sur SVN pendant mon DUT, qui avait le mérite de couvrir les bases).

De ce que j’en ai vu, ce n’est même pas que les personnes sont réfractaires à l’idée d’un gestionnaire de versions, ou quoi que ce soit, mais c’est tout simplement qu’ils n’y ont jamais été introduits.

L’état d’esprit

Pendant mon DUT, on n’a pas arrêté de me dire que de toutes façons, tout le travail sur le code serait bientôt fait en Inde (de ce que j’ai compris, ça fait 20 ans qu’on dit ça, et ça n’a pas bougé), que les « pisseurs de code » ça se trouvait n’importe où et donc qu’il fallait évoluer dans l’« Architecture logicielle » et le management pour avoir un avenir, etc. Pour la majorité des personnes dans cet état d’esprit, n’importe quel codeur vaut n’importe quel autre codeur.

Sauf que non. Le code, c’est à la fois une science, et un art. Imaginer que n’importe qui peut tout faire sans apprentissage, formation, ou motivation, c’est se planter complètement. Ça demande à la fois d’avoir une connaissance de la codebase à un haut niveau, les classes, les fonctions, les bibliothèques utilisées, au niveau de la structure du projet, et enfin, en « bas » niveau, le code, dans ses parties les plus techniques. Ça demande également un bagage théorique, notamment en complexité, et de la culture générale informatique, afin de ne pas réinventer la roue et écrire des algorithmes salement suboptimaux.

Considérer que coder est une tâche « basse », c’est également nier l’expertise technique qui est requise dans un grand nombre de domaines. Bien sûr, ce n’est pas au système éducatif de nous spécialiser dans des niches, d’autant que nous sommes dans un domaine où elles évoluent toujours plus vite, mais ce n’est pas non plus une raison pour faire comme si on n’en avait pas besoin.

Ça date

Si je fais un tour dans les « notes de cours » de ma formation actuelle, il me suffit de télécharger un ensemble de documents pour me rendre compte de l’état de décrépitude de la chose.

• Le poly sur LaTeX parle d’un temps où beamer n’existait pas, et hardcode les accents horriblement (2005)
• Le poly sur le HTML parle d’un temps que j’ai à peine connu (2004), et reprend un poly encore plus vieux sur le sujet.
• Introduction à la programmation avec CAML (pas OCAML, CAML) (2001)
• Javascript et Ajax : 2004 & 2009 (celui là est encore relativement à jour, en dehors de l’omniprésence actuelle de JQuery)
• Langage EIFFEL (…)
• Langage PHP (…) 4 (……)

Les parties théoriques, elles, datent aussi pour certaines, mais ce n’est pas un problème en soi, car la technologie évolue beaucoup plus vite que la théorie. La théorie des langages n’a par exemple pas bougé d’un iota (dans les parties traitées), et il en est de même pour les probas, l’algorithmie et les langages formels.

Encore une fois, je suis d’accord avec l’idée que former des spécialistes sur la dernière technologie à la mode est une perte de temps totale, mais ça ne veut pas dire pour autant que les ressources pédagogiques utilisés doivent dater du siècle dernier. Je pense que les gens devraient être formés à des méthodes, en se familiarisant avec des outils actuels. En clair, véritablement appliquer le mantra « apprendre à apprendre », plutôt que de perpétuer un certain cargo cult de la technologie.

Peut-être qu’une partie des élèves finiront comme programmeurs COBOL pour un grand établissembent bancaire, travaillant effectivement sur des outils et du code datant de mathusalem, mais ce n’est pas une raison pour habituer les étudiants à des outils austères qui ont été complètement remaniés et n’existent même plus sous cette forme aujourd’hui.