Bonjour,
Merci aux 51% d'étudiant.e.s qui ont répondu à l'évaluation et fourni 78 commentaires. J'ai également reçu le feedback plus spécifique sur les séances d'exercices sur lequel j'ai eu une réunion avec mes collègues qui enseignent en 1ière année. Vous aurez une dernière opportunité de fournir votre avis sur ce qu'il faut modifier/conserver car la faculté IC vous demandera une évaluation plus détaillée en fin de semestre.
Je me concentre sur les points à améliorer en complètant ma réponse avec des éléments déjà fournis en ICC ou en cours de semestre car plusieurs points portent sur des questions de méthode de travail en préparation du métier d'ingénieur.e.
1) Session d'exercices / Assistants :
Le nombre d'assistant.e.s est contraint par le budget que les sections peuvent mettre à disposition et par la disponibilité d'assistant.e.s compétents. Cela dit leur nombre est adapté au cours du temps ; par exemple j'augmente les heures de support avant les échéances importantes.
Nous pouvons tous ensemble améliorer l'efficacité des assistants et ainsi réduire les temps d'attente comme suit:
=> 1.1 : vérifier si votre question a déjà été répondue en faisant une recherche par mot-clef sur Discourse (fonctionne presque en 24/7)
=> 1.2 : travailler en groupe sur la résolution des problèmes ; certains groupes ont une trop grande proportion de travail individuel isolé. En effet la résolution de problèmes est beaucoup plus efficace en travaillant en paire (pair programming) car la verbalisation à voix haute nous demande un effort supplémentaire pour mettre de l'ordre dans nos idées, ce qui souvent apporte des éléments de solution qu'on n'obtiendrait pas autrement.
=> 1.3 : préparer vos questions à destination de l'assistant.e après la recherche par mot clef (1.1) et la phase de discussion (1.2) comme indiqué dans un message précédent. Vous devez avoir immédiatement à disposition:
1) une description complète du problème :
1.1) Compilation: message d'erreur du compilateur / fichier correspondants ouverts en édition à la ligne indiquée par la PREMIERE erreur détectée par le compilateur
1.2) Edition de liens: message d'erreur de l'éditeur de liens (= undefined reference) / Makefile et fichier correspondants ouverts en édition
1.3) exécution: faire afficher dans le terminal la valeur des variables qui n'ont pas la valeur attendue
2) un diagnostic: vous devez avoir fait l'effort de formuler à voix haute votre hypothèse concernant ce qui n'est pas correct. Votre phrase peut commencer par "C'est comme si.... ". Faite cela AVANT l'arrivée de l'assistant.e.
C'est dans la nature même des projets du monde réel d'avoir des données incomplètes qu'il faudra préciser avec vos interlocuteurs. La capacité à identifier ce qu'il faut clarifier dans la description d'un problème est l'une des qualités centrale de l'ingénieur.e. Cela était déjà résumé dans l'introduction du document de conception d'algorithme du cours ICC que je cite ici:
1 De la donnée du problème à l’ébauche de l’algorithme
Le titre de cette section suggère implicitement deux croyances naïves qu’il faut tout d’abord identifier pour faciliter la résolution d’un problème :
• Mythe de la donnée univoque :
Une donnée univoque pourrait se traduire quasiment mot à mot en un programme car elle ne contient aucune ambiguïté. Malheureusement, la donnée étant écrite en langage naturel, il existe très souvent des possibilités d’interprétations différentes entre ce qu’a voulu exprimer la personne qui l’a rédigée et ce qu’a compris la personne qui la lit. C’est pourquoi il est tout à fait normal de poser des questions sur la manière d’interpréter la donnée d’un problème.
• Mythe de la solution unique :
La majorité des problèmes accepte une grande variété de solutions, certaines étant plus efficaces que d’autres. Nous recommandons de ne pas hésiter à explorer plusieurs voies dans une première phase pour ensuite vous concentrer sur celle qui présente les meilleurs atouts.
Plus difficile : il faut garder l’esprit ouvert et savoir accepter de remettre en question une approche sur laquelle on a déjà investi du temps car finalement elle est peu performant
Discourse est l'outil idéal pour cette interaction ; la recherche par mot-clef est la compétence transversale que vous devez développer pour être efficace sur ce point. Enfin, Discourse offre un mode anonyme si vous avez encore des hésitations à votre question.
3) nombre de crédits insuffisant pour le cours C++ PoP
Je suis d'accord qu'un cours orienté projet comme celui-ci devrait avoir plus de crédits comme les sections SV, MA et PH.
Comparé aux cours de base (Analyse, Physique), la principale difficulté est de calibrer l'effort que l'on consacre au projet car on a toujours l'impression de pouvoir atteindre les objectifs en y consacrant plus de temps (cf ci-dessous).
Cependant le temps passé sur le projet dépend aussi énormément de votre méthode de travail (seul ou en groupe) comme décrit au point 1. La série1 théorique sur le développement de projet devrait être prise plus au sérieux pour l'organisation du travail.
Une autre difficulté est liée au fait que beaucoup de temps peut être perdu dans la recherche de bug du fait d'erreurs d'inattention ou d'un manque de discipline de programmation. Le travail en paire (pair programming) permet de travailler beaucoup plus efficacement dans la phase de recherche de bugs. ; il faut éviter de rester seul dans cette phase.
J'ai aussi l'impression que certains groupes n'ont pas suffisamment tiré parti des séries0 dont le but ce semestre était surtout d'apporter des fonctionalités faciles à adapter pour avancer efficacement sur le projet.
Cette année j'ai supprimé certains éléments du cours qui ne sont pas utiles pour le projet (graphes) et j'indique les exercices du MOOC qu'il n'est pas requis de faire pour se donner du temps pour les compléments utiles au projet. Je continuerai dans ce sens l'an prochain mais je ne vois plus trop quoi couper (donnez-moi des idées dans le feedback final). On aura toujours besoin de lire un fichier de configuration et d'avoir une interface graphique pour rendre le projet plus intéressant que celui d'automne. Le programme du C++ est calé sur le MOOC OO ; on pourrait éventuellement couper l'héritage multiple.
4) Divers:
4.1) "Faire des résumés": je complèterai cet aspect "résumé des points importants" dans l'évolution du cours
4.2) calendrier sur 7 semaines de cours et projet sur 12 semaines: il y a eu 2-3 remarques sur ce point mais comme vous n'avez pas le recul du semestre complet je préfère avoir plus d'avis en fin de semestre sur le fait de conserver cette structure (oui/non?) ou si "non" comment faut-il la modifier.
4.3) "vieux outils" / C++11, GTKmm, geany:
=> je vais demander si une nouvelle version du MOOC est prévue
=> GTKmm V3: on est contraint par la version du système de la VM ; j'aurai une réunion sur l'évolution de la VM fin mai
=> geany : ce choix très "basique" est voulu pour faire la distinction entre éditeur/compilateur/debuggeur. On n'empèche personne d'utiliser l'environnement de développement dont ils sont familiers.
