Comment puis-je gérer l'attitude de programmation culte du cargo?

J'ai des étudiants en informatique dans un cours d'introduction obligatoire à la programmation qui voient dans un langage de programmation un ensemble de sorts magiques, qui doivent être lancés pour obtenir un effet (au lieu de le voir comme un moyen flexible d'exprimer leur idée de solution) .

Ils ont tendance à copier-coller du code d'assignations antérieures similaires, sans tenir compte de l'essence du problème.

Existe-t-il des exercices ou des analogies pour donner à ces étudiants plus de confiance en leur capacité de comprendre et de comprendre la structure et la signification de chaque morceau de code écrit?

Vous pouvez leur présenter une série d'exercices, chacun reposant sur le précédent tout en ajoutant un élément supplémentaire ou en modifiant le problème ou en examinant le problème sous un angle différent, ce qui révèle une faiblesse de la solution précédente, nécessitant une nouvelle approche différente. . Cela les oblige à réfléchir, analyser, modifier et expérimenter chaque solution plutôt que de simplement copier-coller un morceau de code prêt à l'emploi.

Une autre possibilité - bien que n'étant pas strictement une tâche de programmation - est de leur demander d’ estimer différentes choses. Par exemple, combien d'eau traverse le delta du Mississippi par seconde? Ces questions n'ont pas de réponse prédéfinie, en particulier parce qu'il est nécessaire de formuler certaines hypothèses pour obtenir une (des) valeur (s) convaincante (s). Et - bien que les réponses à beaucoup de ces réponses "classiques" puissent être recherchées - vous pouvez facilement en créer de nouvelles qui ne se trouvent (encore) nulle part sur le net.

Vous trouverez des exemples de ces deux types d'exercices dans par exemple, Programming Pearls de Jon Bentley. Aussi Le Pragmatic Programmer a quelques bons défis.

Un troisième type de tâche consisterait à leur présenter un élément de code contenant un (ou plusieurs) bogue (s), qu’ils doivent trouver et corriger. Cela les oblige à nouveau à utiliser leurs compétences analytiques et à expliquer le fonctionnement réel du programme.

Mise à jour

Commentaires d'un commentaire de Billy ONeal:

Le problème avec la "série d'exercices" est que les étudiants qui ont un problème avec un exercice précédent sont complètement foutus pour les exercices restants.

Vous avez raison, même si j’estime qu’il s’agit plus du problème général de régler la difficulté du cours au bon niveau / de regrouper des étudiants de niveau similaire. De plus, on peut organiser les étudiants en groupes plus petits où ils doivent discuter et débattre des problèmes et des solutions, et résoudre les problèmes ensemble. Si quelqu'un ne l'obtient pas, les autres peuvent aider (cette configuration améliorerait également les compétences de travail en équipe). Et si quelqu'un essaie d'être paresseux et de laisser les autres faire tout le travail, il est sûrement remarqué par l'enseignant (qui est censé se promener, superviser et guider les étudiants, sans jouer à WoW sur son ordinateur portable dans un coin ;-)

Et on peut aussi ajuster les exercices pour adapter les élèves à différents niveaux de compétence. Les débutants peuvent aller plus lentement, les plus expérimentés plus rapidement.

Vous vous battez pour que les étudiants s'équilibrent entre le besoin de s'occuper de votre sujet et le besoin d'obtenir des notes de passage . De nombreux étudiants estiment que:

(Faites-le mal || Expérience) == (Échec de la note && perte de temps)

Dès qu'un élève sent que son temps ou sa classe est en danger, même pour une matière intéressante, il arrête d'apprendre et passe directement à «Je m'en fous, donnez juste à l'enseignant la bonne réponse». Vos étudiants essaient de couper les coins ronds (ou du moins ils le pensent) en réfléchissant le moins possible au problème et en le corrigeant simplement en copiant / collant.

Voici mes suggestions sur la façon de gérer cela:

1. Utilisez la méthode de Bob Ross: Montrez-leur qu’il est à la fois possible et plus rapide de recommencer à zéro par rapport au copier-coller. Créez de nouveaux programmes sous leurs yeux pendant les cours - montrez-leur vraiment que la programmation peut être comme une peinture.
2. Fournir des tâches qui nécessitent de la créativité . Par exemple, demandez à chaque élève de créer ses propres structures de données (quels sont les objets nécessaires pour créer un zoo, un animalerie, une ville, un collège, etc.) sur papier à utiliser tout au long du cours. La deuxième tâche peut consister à convertir ces structures en classes ou en objets, etc. En résumé, incitez-les à penser de manière abstraite - récompensez-les pour leur créativité, puis récompensez-les pour avoir transformé leur créativité en programme informatique.
3. Utilisez le moins de syntaxe possible. Des éléments tels que la création de classes et la syntaxe de langage sont tellement répandus dans l'introduction de la programmation que les étudiants sont amenés à croire que toute la programmation consiste simplement à savoir où mettre des accolades - elles ne se rendent pas compte que ce qui se trouve au milieu accolades est l'endroit où la créativité coule . Choisissez un langage simple et fournissez des exemples de fichiers (tels qu'un fichier de classe vide) aux étudiants qui souhaitent toujours copier et coller quelque chose. Vous pouvez progressivement devenir plus strict en ce qui concerne la syntaxe et les tâches compilables à mesure que le cours avance.

Plusieurs choses me viennent à l’esprit:

• Donnez-leur des devoirs où ils doivent réellement expliquer le code écrit par quelqu'un d'autre (vous). La compréhension du code précédent, ou plus précisément son absence, constitue à la fois la principale cause et le plus grand danger de la programmation culte de la cargaison. Leur demander d'utiliser des commentaires, ligne par ligne si nécessaire, pour expliquer votre programme en anglais simple (ou selon la langue humaine que vous utilisez).

• Seulement après qu'ils ont expliqué le code, demandez-leur de le modifier afin de faire un certain changement. Par exemple, si vous leur avez attribué une fonction de tri décroissant, demandez-leur de trier par ordre croissant. Ou quelque chose de plus exigeant. Mais assurez-vous que c'est quelque chose qui nécessite la compréhension du code donné.

• Vous pouvez, si vous le souhaitez, mettre des œufs de Pâques dans le code. Une ligne ou deux qui ne fait rien d’utile ni même qui est lié au problème. Donnez-leur un indice que de telles lignes existent et accordez des points supplémentaires à ceux qui les suppriment.

• Ensuite et seulement à ce moment-là, vous pourrez leur donner la tâche d'écrire un morceau de code à partir de rien. À ce stade, ils devraient avoir une bien meilleure compréhension de ce qu'est réellement le code. Ils pourraient même trouver un peu plus facile de le faire eux-mêmes.

L'idée de base est que la programmation ne consiste pas seulement à écrire du code, mais également à le lire. La lecture du code devrait également être enseignée.

Regardez-le d'une autre manière. Ce phénomène culte de la cargaison est la phase novice du modèle d’acquisition des compétences de Dreyfus . Ça c'est comment qu'on apprends. Lorsque j'ai appris à programmer, tout ce que je faisais était de taper des pages de code à l’arrière de Compute! magazine. La répétition est la clé. Les bébés apprennent à parler en copiant les sons entendus par leurs parents. Tout ce que nous apprenons se fait par imitation. Nous devons juste apprendre à passer de l'imitation à la maîtrise.

Le problème que vous avez, c'est que vos étudiants ne répètent rien, ils le copient depuis Internet. Cela présente certains avantages, mais les gains sont minimes. Le fait de taper le code est ce qui m’a amené à comprendre. J'ai commencé à voir des modèles dans ce que je dactivais et j'ai acquis une compréhension de ce que je faisais.

Une option consiste à structurer votre laboratoire en un dojo de code. Demandez aux élèves de se jumeler à tour de rôle sur le même problème. Choisissez un problème qui prend environ 10 à 15 minutes à résoudre. Répétez ce problème sur quelques laboratoires et apportez une nouvelle tournure au problème au fur et à mesure que la classe gagne en compétence. Commencez peut-être le laboratoire en demandant aux étudiants de vous regarder programmer la solution et de la répéter. Changer de paires à chaque itération.

Pour vos tests, utilisez un code kata dans lequel chaque élève résout les problèmes du semestre devant le reste de la classe. Concentrez-vous non seulement sur l'exactitude, mais également sur la forme et la créativité. Je pense que cela fournirait une meilleure compréhension de la façon de programmer que de donner des devoirs à la maison.

J'ai déjà enseigné des cours d'initiation et, si je me souviens bien,

Certains étudiants pensent que la programmation est comme ça pour différentes raisons. Je me souviens que jadis, un bon enfant a beaucoup cultivé ce que j'ai fait dans le transport de marchandises:

Croyant qu'il ne s'agissait pas d'un problème isolé, mais que d'autres élèves de la même classe pouvaient avoir un comportement similaire ou appréhender le problème et ne pas l'exprimer, je m'adressais toujours à la classe.

1. Un certain temps a été passé pour expliquer des éléments tels que le déterminisme, ce qui signifiait pour eux que dans le même environnement avec les mêmes données et code, ils obtiendraient les mêmes résultats (dissiper le "caractère aléatoire"),

2. Étant donné que la résolution de problèmes dépend des actions de l'élève et non de rien d'autre, il convient de prêter attention à la résolution du problème et non à la recherche du bon sort,

3. Comme ils sont dans un environnement éducatif, les problèmes sont conçus de manière à offrir une expérience d’apprentissage; le résultat est d’apprendre à programmer (ou dans certains cas, comme des cours pour administrateurs système, comment les programmes fonctionnent, ce qui est différent) et non à donne moi une solution. ("World n’a pas besoin d’une autre calculatrice, c’est un exercice"), donc leurs problèmes pourraient être résolus avec le matériel disponible (exemple: notes fournies),

4. Je pense que c'est dans Code Complete: "Même si vous copiez et collez, le code est à vous". Si quelqu'un le faisait, il ne devrait pas s'agir d'un cargo. Chaque ligne devait être expliquée à moi (individuellement) ou à un autre étudiant (même) ou à la classe.

Vos étudiants ont-ils commencé avec le «niveau d'abstraction» correct au début du cours? Par exemple, un devoir qui leur présente les principales structures de programmation, telles que les boucles et les conditionnelles, sans écrire une seule ligne de code?

Quand j'ai commencé la programmation, notre première mission s'appelait « Rick the Robot ». Nous avions un morceau de papier avec une carte aérienne d'une ville avec des points intéressants, comme des banques, des épiceries, etc. 'regarde bien', 'traverse la route' et nous pourrions utiliser des choses comme 'répéter' et 'si quelque chose, alors fais quelque chose'. (Ce n'est pas à 100%, car je ne pouvais pas trouver cette tâche.) L'idée était que Rick ne pouvait utiliser que ce qui lui avait été donné et qu'il devait se rendre à différents endroits sur la carte.

C'était un exercice amusant et quelque chose qui vous a présenté les bases (qui sont parfois les plus difficiles à comprendre pour les nouveaux arrivants). Il n’existe pas de bonne réponse à ce problème (c’est un jeu) et il n’existe aucune solution pour copier / coller. Quelque chose comme cela pourrait également vous permettre de jouer un peu plus avec leur créativité sans les intimider avec du code.

Enfin, l’idée est de commencer par l’ abstrait et de progresser vers le concret . Ils ne peuvent pas copier le résumé en pâte. Ils doivent le comprendre pour résoudre un problème.

Ce que vous leur demandez de faire, c'est de démontrer l'analyse et la synthèse dans le domaine cognitif de la taxonomie de Bloom , où ils ne font actuellement que démontrer une application.

Malheureusement, il s’agit en quelque sorte d’une situation du type «guide le cheval l’eau». L'analyse et la synthèse sont également très difficiles à réaliser lorsque vous avez encore du mal à comprendre. Sans la compréhension en place, les activités d’analyse et de synthèse agiront davantage comme activités d’extinction que comme activités d’apprentissage.

Mon opinion personnelle est qu'il est normal de ne rien attendre de plus que des applications en introduction aux classes de programmation. C'est la première fois que les élèves sont exposés à ces concepts. C'est donc comme apprendre aux enfants à lire avant de leur demander d'écrire une dissertation. Ces compétences d'ordre supérieur suivront dans leurs cours ultérieurs.

Avez-vous envisagé de leur fournir un code pour commencer? Quel que soit le simple échafaudage dont l'assignation a besoin, par exemple une fonction principale vide (je ne sais pas quelle langue vous utilisez). Quelque chose qui compile et fonctionne et ne fait rien. Ensuite, ils peuvent commencer à ajouter leur code avec une certaine assurance qu’au moins une partie de celui-ci fonctionne.

C'est en fait assez commun dans le "monde réel"; beaucoup d'EDI et d'autres outils créent des projets vides avec des bibliothèques / modèles / fichiers de configuration typiques déjà en place.

Toute mentalité de culte du cargo (y compris les cultes du cargo ) découle d'un manque de compréhension fondamentale de la technologie impliquée.

La programmation culte du fret ne devrait pas être considérée comme une habitude problématique, mais plutôt comme un symptôme de la confusion sous-jacente à laquelle le programmeur est confronté.

Plus important encore, l'hypothèse selon laquelle le manque de compréhension de l'élève est simplement le résultat de son manque de confiance en soi est fondamentalement erronée et ne résout pas le problème sous-jacent.

Au lieu de cela, le style de programmation de copier-coller de l'élève devrait être un drapeau rouge vous indiquant que cet élève est submergé par la complexité de ce qu'il est censé faire.

Il utilise instinctivement les travaux antérieurs comme un échafaudage sur lequel construire son projet actuel, essayant de composer une solution en utilisant des problèmes précédemment résolus comme blocs de construction. Nous le faisons tous dans une certaine mesure, mais la plupart d’entre nous le faisons en nous inspirant des connaissances acquises au cours de travaux antérieurs. Au lieu de cela, cet étudiant utilise le travail lui-même, ce qui signifie qu'il ne comprend pas vraiment les blocages avec lesquels il travaille. Il a décomposé le travail dans la mesure où sa compréhension le permet et a traité de gros blocs de code comme des unités atomiques, car il ne comprenait pas comment ils fonctionnaient . Il sait seulement ce qu'ils font.

Changez votre idée de projets!

Dans le monde de la programmation, nous créons rarement de nouveaux projets pour chaque solution proposée. La plupart du temps, nous modifions les anciens.

Changez votre idée de projet d'une solution pour chaque mission à une solution pour tout le semestre. Chaque affectation s'appuie sur l'attribution précédente.

Exemple

Projet: Construire un système d'ascenseur

• Devoir 1: Imprimer l'étage actuel
• Devoir 2: Créer les structures de données pour une classe d'ascenseurs et imprimer le sol en fonction de l'ascenseur
• Devoir 3: Créez un code qui "déplace l'ascenseur" en imprimant le sol. Accepter la saisie au clavier (> entrez le sol:)
• Devoir 4: Gérer plusieurs ascenseurs

Le fait est que vous vous appuyez sur la précédente affectation au lieu de recycler les anciennes affectations pour une nouvelle tâche.

Pensez à utiliser un langage de très haut niveau nécessitant un minimum de code passe-partout.

Pour moi, c'est souvent le code standard dans les grands frameworks ou les langages verbeux qui se sentent comme des sorts magiques et empêche la compréhension.

J'ai personnellement appris le ML à mon cours d'introduction à la programmation en CS. Pendant de nombreuses années, Lisp a été enseigné comme introduction à la programmation au MIT. Les deux sont d'excellents choix. Certains des avantages qu'ils ont sont

• Interprète interactif. Très important car cela permet l'exploration.
• Très succinct. Pas de passe-partout du tout. Cela permet aux étudiants de se concentrer sur les idées qu'ils essaient d'exprimer.
• Relativement obscur et étranger (du moins par rapport à Java, C ou d’autres langages traditionnels que les étudiants ont déjà une certaine expérience). Oui, je liste cela en tant que pro. Il nivelle le terrain de jeu pour les étudiants, étant donné que probablement personne n'aura une expérience antérieure. Et il est donc moins probable qu’ils soient en mesure de copier / coller des solutions aux devoirs à partir du Web.

J'ai fait des recherches sur les problèmes des programmeurs débutants dans les années 80. D'après mon expérience avec les programmeurs débutants aujourd'hui, peu de choses ont changé. Les novices n’ont pas de modèle mental utile de ce que font réellement les ordinateurs. Ils ont recours à des incantations magiques parce que la machine elle-même est magique.

La programmation nécessite de décomposer des tâches naturellement simples en petites étapes anormales. Étant donné que les novices ne traitent pas avec une telle granularité dans la vie quotidienne, ils ont du mal à comprendre ce que devraient être les petites étapes, en particulier lorsqu'il est difficile de savoir quelles petites étapes la machine met à disposition. Mais même s’ils parviennent à comprendre cela, ils sont alors confrontés à la syntaxe figée et à la sémantique limitée d’un langage de programmation (langage artificiel se faisant passer pour un système quasi naturel) qui contrôle la machine mystère à distance.

Puisqu'ils ne peuvent pas faire le lien entre une solution logique au problème et la fonctionnalité de la machine, ils s'attachent à satisfaire les exigences du langage. Le premier objectif est d'écrire quelque chose - n'importe quoi - qui compile. La seconde consiste à modifier ce programme - quoi qu’il fasse réellement - pour l’empêcher de tomber en panne. Ensuite, s’ils ont le temps, l’énergie et l’intérêt voulus, ils essaient de faire en sorte que le programme produise des résultats qui ressemblent à ceux que le problème nécessite. En cours de route, ils peuvent produire accidentellement un code bien écrit.

Selon toute vraisemblance, les novices qui apprennent à programmer réussissent parce qu’ils ont déduit un modèle mental utile de l’ordinateur, et non parce qu’ils en ont été dotés intentionnellement et qu’ils l’ont intériorisée.

Vous pourriez leur poser des questions sur des éléments de code nécessitant des réponses écrites? Comme "Qu'est-ce que ce code fait?" "Pourquoi le programmeur l'a-t-il résolu comme ça?" "Y a-t-il un meilleur moyen?", Etc.

Cela les incitera effectivement à réfléchir au problème, ce qu’ils peuvent faire sans même toucher au code.

• Les mettre au défi de créer les solutions les plus courtes possibles au problème.
• Récompenser les solutions les plus succinctes avec une incitation.
• Créez des exercices qui tournent entièrement autour du code de refactoring
• Demandez aux élèves d’échanger leurs devoirs et de les évaluer en fonction de l’efficacité et de la propreté du code, et d’utiliser certains des moins efficaces comme exemples, sur un rétroprojecteur.

Une idée similaire à celle de JoelFans est qu’ils fassent les premières tâches sur papier en utilisant un pseudo-code (langage) que vous créez. Vous pouvez ajouter les structures comme bon vous semble et elles ne s’inquiètent pas de la boîte magique.

Je vais supposer que par «culte du fret», vous voulez dire qu'ils insèrent des éléments jugés nécessaires, mais ne font absolument rien pour résoudre le problème.

Si tel est le cas, vous pouvez toujours ajouter un facteur dans la classification basée sur la concision - laisser du code inutile ou redondant dans votre programme pose des problèmes à l'avenir, car il risque de tomber en panne ou de le rendre plus difficile à maintenir.

Ils seraient jugés de la même manière lors d'un exercice d'écriture dans un cours d'anglais - personne ne veut de choses qui se déroulent dans une tangente aléatoire ou qui sont généralement en train de divaguer sans aller au fond des choses.

Lorsque je prenais un cours d’assemblée, le professeur nous indiquait pour chaque exercice s’il souhaitait que nous écrivions le code de vitesse, de taille ou d’utilisation de la mémoire, et il le marquerait si vous ne parveniez pas à optimiser ce qu’il demandait. pour.

...

S'ils copient et collent du code provenant d'assignations similaires précédentes, et que c'est en fait quelque chose qui résout le nouveau problème ... eh bien, il ne s'agit que de la réutilisation de code, et à moins qu'ils ne fassent de mauvaises hypothèses sur l'aptitude du code à être réutilisé , Je pense que c'est parfaitement raisonnable pour eux de le faire. (par exemple, lire dans un fichier, solliciter une entrée ... toutes les parties modulaires qui peuvent être réutilisées. Si vous ne le souhaitez pas, vous devez rendre les exercices différents.

Malheureusement, c'est la façon dont travaillent beaucoup de cerveaux. Alors, comprenez bien qu'il y a des gens avec qui vous ne pouvez pas guérir. Beaucoup de gens sont incapables de travailler avec le niveau de précision mentale nécessaire pour programmer. Certaines personnes ne sont tout simplement pas conçues pour cela. Je ne dis pas abandonner les étudiants - je ne suppose pas que vous échouez si tout le monde ne le prend pas.

Sans en savoir plus sur le contexte de la classe, je dirais que vous devez vous concentrer davantage sur ces structures de base: simples si / thènes, boucles, etc. plus de 10 lignes de code chacune. S'ils sont "en train de penser à la magie", ils n'ont manifestement pas encore maîtrisé ces bases. Demandez-leur de faire beaucoup de routines simples jusqu'à ce qu'ils comprennent ce qui se passe. Quelqu'un d'autre a parlé d'écrire le code sur papier - je pense que ce serait aussi un excellent moyen de faire ces routines simples.

Vous pouvez également envisager de leur faire apprendre la cartographie. Pour certaines personnes, il peut être utile de pouvoir visualiser le flux d'un algorithme, puis comment il se connecte au code, pour connecter le code au flux.

Idéalement, lors de la première conférence, commencez avec quelque chose de complètement abstrait: demandez-leur (en groupe, avec vous en tant que leader) de rédiger les instructions sur la marche à suivre pour faire les courses à partir d'une liste et de décomposer progressivement les instructions de haut niveau. jusqu'à ce qu'ils atteignent l'illumination.

Il est utile de leur dire que ces instructions vont être suivies à la lettre par un robot, qui ne sait pas comment en déduire. Ce doit être une activité très pratique où vous êtes chargé de les guider, cependant.

Alistair Cockburn parle du concept de Shu-Ha-Ri et de son application à la programmation, http://alistair.cockburn.us/Shu+Ha+Ri . Je pense qu'il peut être important de garder à l'esprit où vos étudiants sont dans ce continuum. Premièrement, cela aidera à atténuer une partie de votre frustration. Copier / imiter est une réponse très naturelle et acceptée lorsque vous commencez à apprendre quelque chose. Deuxièmement, cela peut vous aider à avoir des idées sur la façon d'aller de l'avant. Par exemple, vous pouvez envisager de choisir un problème qui peut être résolu de différentes manières (boucles / récursivité, console / web / interface graphique), puis de le laisser explicitement d'abord le résoudre d'une manière, puis d'une autre manière - un bonus à apprendre sur la réutilisation légitime du code, la composition en composants, la création de bibliothèques réutilisables, etc.

Un autre moyen efficace que j’ai déjà utilisé est d’avoir une série de projets qui s’enchaînent les uns sur les autres, rendant une version fonctionnelle par défaut disponible à chaque étape après la remise des tâches afin d’empêcher les gens de prendre du retard. Chaque étape du processus devrait introduire quelque chose de nouveau. Je vous concède que cela peut être plus facile à faire dans un cours de conception que dans un cours de programmation, mais cela devrait quand même être faisable. Une bonne chose à ce sujet est que vous leur donnez explicitement une bonne implémentation (espérons-le) à comparer avec la leur à chaque étape. Exposer cette comparaison en tant que tâche, c’est-à-dire effectuer une révision de mini-code de leur propre code par rapport à leurs efforts Vous voudrez peut-être choisir parmi plusieurs options de crédit supplémentaires.

Bien que je ne sois généralement pas très féru de "commentaires", vous souhaiterez peut-être faire de la documentation du code l'un des éléments de qualité. Demandez-leur de produire un document "Théorie de fonctionnement" pour chaque projet, décrivant leur approche, la place de chaque composante et la manière dont ils résolvent ensemble le problème. Normalement, je souhaiterais que le code s’applique lui-même en grande partie, mais cela les pousserait à mettre leur casse-tête à l'esprit et à le mettre sur papier.

Enfin, vous voudrez peut-être faire preuve de créativité et demander à vos étudiants de passer en revue le code de chacun et de l'évaluer. Mettez la pression des pairs à travailler pour vous. Permettez à cela de faire partie de la note ou du crédit supplémentaire pour le code le mieux noté (et la documentation).

Juste une suggestion rapide. Chaque fois que j'ai un problème de programmation qui doit être résolu ou débogué, j'aime bien regarder mon code et "jouer à l'ordinateur". Dans ma tête, je garde une trace des variables et de leurs valeurs, ainsi que de ce à quoi je m'attends lors de l'exécution de chaque ligne. . Donc, si j'ai copié du code quelque part, à moins qu'il soit complet et qu'il faille le référencer, j'aime aller ligne par ligne pour comprendre exactement ce qui se passe. Essentiellement jouer à l'ordinateur. Le débogueur VBA facilite essentiellement cette tâche, mais le fait de le faire sur papier pour les étudiants peut leur donner les bases suivantes. Que fait réellement cette ligne?

J'ai enseigné la programmation d'introduction au niveau collégial. C’était un cours de pain et beurre, tous les professeurs l’ont fait, et je pense que nous l’avons très bien fait. Nous avons suivi un texte commun et passé des examens communs, mais nous avions chacun notre propre méthode de classe qui fonctionnait. Cela fait longtemps depuis, mais il m'est parfois arrivé de donner des cours à des enfants en programmation, et la situation est à peu près la même.

La façon dont je le fais est de commencer par le bas, le plus concret possible. Ce que les élèves savent est une structure. Ils ont déjà beaucoup de concepts. Je construis d’autres concepts en plus de ceux-ci, et j’élague les concepts qu’ils pourraient former, qui sont contre-productifs. En même temps, je les fais apprendre par la pratique .

J'avais construit un petit ordinateur avec une puce Intel 8008, de la mémoire EPROM et quelques circuits. Je l'avais programmé pour jouer un petit duo lorsque la puce d'E / S était connectée à quelques haut-parleurs. Je voudrais expliquer le fonctionnement du petit programme, avec une boucle interne pour décompter un compteur. Cela agirait comme un retard. Ensuite, il basculerait le bit de sortie et le referait. Il ferait cela pendant un moment, puis passerait à un autre délai, en donnant un autre ton, etc. La puce de mémoire avait une petite minuterie, et si je rangeais un conducteur de condensateur sous l’une des entrées de la minuterie, le programme fonctionnerait lentement . La classe pouvait entendre les conférenciers cliquer, cliquer, cliquer ... Je voulais que la classe comprenne que l'ordinateur faisait des choses très simples, une étape à la fois.. Ensuite, je déconnecterais le condensateur et la "musique" éclaterait. (applaudissements)

Ensuite, j’avais construit un simulateur pour un ordinateur décimal très simple, comportant 1 000 emplacements de mémoire, chacun contenant un nombre décimal signé à 4 chiffres. Il y avait des opcodes très simples comme "ajouter à l'accumulateur", "sauter si négatif", etc. Je leur ferais écrire de petits programmes dans ce "langage machine", comme ajouter deux nombres ou une liste de nombres. Ensuite, ils pourraient le regarder fonctionner en marchant seul ou en maintenant la touche Entrée enfoncée pour le regarder courir "rapidement".

L'objectif était de mettre en place le concept selon lequel les ordinateurs ne peuvent effectuer qu'un très petit nombre d'opérations de base différentes, et ils les effectuent une à la fois. C'est pour contrer l'impression qu'ils ont que les ordinateurs sont compliqués, et qu'ils font tout en même temps, et lisent dans leur esprit.

Nous avons ensuite programmé dans un "vrai" langage (BASIC :), en commençant par des programmes très simples mais intéressants, en passant par les conditions, les boucles, les tableaux, les fichiers, la fusion, etc. L'objectif était de mettre en place un ensemble de compétences suffisant pour qu'ils puissent entreprendre un projet de leur choix, car c'est la seule chose qui rend la programmation intéressante - l'utilisation à laquelle vous pouvez le consacrer. Je jetais quelques idées de projets, puis ils partaient de là. Je voudrais demander des idées écrites, puis des rapports d'activité, pour les empêcher de le reporter à la dernière minute et ensuite de paniquer. Je pense que les projets étaient la meilleure partie, car ils apprenaient par leurs propres moyens.

Cette connaissance initiale très concrète de ce que font les ordinateurs a rendu beaucoup plus facile l’enseignement ultérieur de concepts qui seraient autrement de véritables ralentisseurs, comme des tableaux ou (dans un cours ultérieur) des pointeurs. Nous avons tendance à glorifier le concept d '"abstraction" en tant que chose merveilleuse, mais il doit être construit sur des fondations concrètes, pas sur des ondes.

Un programmeur autodidacte, je pense que l’ animation est le défi le plus difficile pour savoir ce que fait le code. Lorsqu'un programme contient des algorithmes et des transformations mathématiques effectuant des manipulations abstraites, la seule façon de comprendre ce que les mathématiques font en tout point (sauf si vous êtes un génie) nécessite de comprendre l'exécution du code lui-même.

Corrigez-moi si mon idée naïve est incorrecte. Ce que vous voulez faire est d' notempêcher vos étudiants d'utiliser des "modèles de conception", mais de trouver un moyen de s'assurer qu'ils comprennent ce qu'ils sont CnP? Puis mettez vos élèves au défi de manipuler une animation. Afin de modifier la sortie dans une animation, il est nécessaire de comprendre ce qui se passe à chaque étape. En ce qui concerne votre préoccupation, j'imagine qu'un projet d'animation bien conçu se manifestera de manière évidente lorsqu'un étudiant "comprend" - lorsqu'il a réalisé une transformation que vous ne souhaitiez pas ou modifiait certaines variables interdépendantes liées.

Sans connaître les limites pédagogiques et les objectifs sous lesquels vous travaillez, je ne peux pas dire que l'animation est la réponse complète. Tout un programme d'animations en dehors de la profession d'analyste est, il faut bien le deviner, hors de question. Quelques projets peuvent néanmoins aboutir à quelque chose d'artistique et de merveilleux, ce qui n'est pas mauvais.

Sur une autre note, j'ai lu un article de journal (oui, papier!) Au sujet d'une Olympiade des Jeux Olympiques de codage au secondaire - une guerre pour tous - pour les programmeurs pré-universitaires. La description de leurs défis était l'articulation la plus claire du codage pur, je me souviens de l'avoir lue. Les concurrents sont jugés les uns par rapport aux autres et selon les normes de bonnes pratiques. Pour ces compétitions, les étudiants doivent à la fois planifier leur solution et coder à la main le "modèle de conception" élémentaire que le problème nécessite de terminer dans les délais impartis. Ainsi, la solution à votre problème concernant la programmation CnP est de vérifier si les étudiants peuvent écrire les mêmes "morceaux de code" qu’ils sont CnP'n!

Je suis sûr que c'était dans le NY Times. Une recherche rapide ne l'a pas trouvé. Un exemple similaire est le concours international de programmation universitaire organisé par ACM. Ce concours met l'accent sur la programmation rapide: "La programmation rapide comme l'éclair dans une compétition par équipes est une compétence résolument originale, et ce n'est pas vraiment un chercheur d'emploi qui placerait sa place au sommet d'un CV." Ainsi, je recommanderais l' abstraction des problèmes du monde réel est la réponse.

Aussi,

HP Code Wars

Enseignez à la classe en utilisant un langage de programmation techniquement bon mais tellement obscur qu’ils ne pourront trouver aucun code existant à copier.

Vous pouvez également les traiter à la dure.

Trouvez un moyen de faire un copier-coller qui leur soit préjudiciable. Je n'ai pas d'exemple précis, mais si vous créez un premier exercice dont la solution, si elle est collée dans un deuxième exercice similaire, amenez les étudiants cultes du cargo dans un très long et pénible bogue "instabilité instable" ou "corruption de données silencieuse". Pendant ce temps, une réflexion de "2 minutes non-culte du cargo" aurait apporté une solution évidente même au pire étudiant (n'a-t-il pas vu la première solution d'exercice). Ensuite, ils pourraient peut-être apprendre la leçon et réfléchir à deux fois avant de copier le code dans le troisième exercice.

Je doute que ce comportement soit dû à la conviction que les programmes sont des formules magiques - il est plus probable qu’il s’agisse de paresse et de manque de motivation.

Je pense donc que votre travail en tant qu'enseignant est de motiver vos étudiants - aucun étudiant réellement motivé n'écrira et ne collera une solution (c'est seulement pour les programmeurs qui travaillent avec des délais et des résultats à respecter ...)

Enseigner des sous-routines. Demandez-leur de prendre le code qu'ils ont récupéré lors de leurs précédentes tâches et de le transformer en sous-programme. Apprenez-leur sur la documentation des fonctions pour les aider à comprendre ce que fait le sous-programme.

Demandez-leur de faire le devoir devant vous dans la salle de classe sans accès à Internet (demandez à l’école de le couper, interdisez également l’utilisation du téléphone pendant les cours). Au moins le faire pour les tests. Il n’ya aucune raison du tout qu’ils utilisent Internet pour faire de la programmation de base. Le livre devrait constituer une ressource suffisante pour les exercices d'introduction. Autorisez l'utilisation d'Internet une fois que vous êtes dans une classe avancée et qu'ils ont déjà appris à penser.

Ne leur donnez jamais des tâches similaires.

Ou, plus fou, apprenez-les TDD depuis le début. Cela pousse à écrire (pas à copier, à écrire) beaucoup de code (à savoir des tests) qui aide réellement à formuler le problème en cours de résolution.

Quelque chose que j’ai trouvé très utile pour les élèves de ma classe est la rédaction d’un petit projet sur leur sujet, sur un sujet qu’ils peuvent choisir eux-mêmes.

Quand j'ai commencé à programmer, c'était aussi difficile pour moi et j'ai beaucoup copié en classe. Ensuite, à la maison, j'ai commencé à créer de petits jeux, car je voulais devenir programmeur de jeux et je les ai trouvés beaucoup plus faciles à créer. Même s'ils étaient beaucoup plus difficiles que ce que nous avons vu en classe. Juste parce que ça m'intéressait.

Quelques autres personnes de ma classe sont passées de 40 à 50% de leurs examens à 90 à 100%, car elles ont fait exactement la même chose.

Lorsque j'étais dans un cours d'introduction à la programmation, l'instructeur demandait à tout le monde d'écrire un algorithme en anglais, de l'imprimer et de le rendre avant que nous commencions à écrire du code. Ensuite, nous aurions à mettre plein de commentaires tels que Créer des variables, Obtenir une entrée de l’utilisateur, Effectuer des calculs, Imprimer une sortie, etc. plus. Cela m'a obligé à réfléchir à ce que je faisais, à écrire les solutions et à continuer à traduire entre anglais et Java.