Par : Boris

J'ai eu une formation Informatique à l'ESIEE (Ecole d'Ingénieur) entièrement basée sur la compréhension, pas le savoir-faire. Nous utilisions Java, mais sans en apprendre les librairies. Par contre, nous travaillions à fond sur les Design Pattern, les architectures de données et le temps-réel. Nous écrivions beaucoup de pseudo-langages avant de développer nos classes et parfois les interfaçions avec des morceaux en C++ ou en Java JIT. Bref, nous apprenions les concepts plutôt que les langages. Quand on nous donnait des projets de fin d'année, il s'agissait de projet d'implémentation de recherches avancées. Nous lisions des documentations pendant des semaines, faisions des schémas d'architecture et discutions longtemps avant d'écrire la première ligne de code. Mais une fois écrite, le reste arrivait vite et bien. Cette approche n'a pas que des avantage et j'ai mis quelques mois à comprendre comment mettre en place une structure intellectuelle de démarrage rapide de projet, pour valider un concept avant de dépenser davantage d'énergie dessus. Aujourd'hui j'enseigne à des étudiants à qui on apprend davantage les langages que les concepts et j'essaie de changer la donne (heureusement, <a href="http://blog.alexandredubois.com/2014/05/30/une-annee-scolaire-de-lautre-cote-du-bureau/" title="Une année scolaire de l'autre côté du bureau | Blog d'Alexandre Dubois" rel="nofollow">je ne suis pas seul</a>) mais je vois la différence : quand ils arrivent dans mes cours, ils sont capables de démarrer la première ligne de n'importe quel projet en 5 minutes. En revanche, ils mettent des mois à le finaliser pour un résultat souvent mal réfléchi. J'essaie de changer cette vision en les impliquant en amont, dans la réflexion fonctionnelle, pour qu'ils comprennent que le code n'est qu'un moyen, pas une fin (même si c'est très tentant de vivre pour le code, il y a tellement à apprendre !).