Conseils pour l'enseignement à l'aide de Live Coding

11

Je suis impliqué dans un cours de programmation et d'algorithmes de première année. Dans une récente conférence, j'ai décidé de présenter le matériel en utilisant codage en direct , ce qui signifiait essentiellement que je m'asseyais derrière le clavier et écrivais du code et l'évaluais, en utilisant emacs pour faciliter le processus.

Ce fut un grand succès et les étudiants ont commenté combien ils appréciaient le format plus (inter) actif. Comme c'était ma première tentative en utilisant ce format d'enseignement, je sais qu'il ne fonctionnait pas parfaitement. Certains des problèmes étaient liés au fait de ne pas être emacs que je devrais l'être, et d'autres fait de permettre aux questions des étudiants de m'éloigner trop de mon script. Je sais que je peux faire mieux.

Quelles sont les directives pour donner des conférences (et autres démonstrations) en utilisant des conférences de codage en direct?
Quels sont les pièges à éviter?

Dave Clarke
la source
2
J'ai mes réserves sur le codage en direct (concernant principalement le débit et l'illusion de la compréhension). Néanmoins, deux suggestions: 1) Avez-vous envisagé d'utiliser des systèmes de réponse en classe pour structurer les questions? 2) Je ne sais pas à quel point c'est pratique, mais utiliser quelque chose comme ideone.com peut être intéressant parce que les étudiants peuvent accéder à votre code après la conférence et l'exécuter sans avoir à installer des trucs.
Raphael
@Raphael: J'ai eu leur attention beaucoup mieux qu'avant, ce qui est certainement un plus. Vos deux suggestions sont très bonnes. 1) Actuellement, seules les personnes qui suivent vraiment offrent une rétroaction. 2) Ma langue n'est pas sur la liste. Cela dit, tout le code est disponible dans des diapositives (que j'ai ignorées).
Dave Clarke

Réponses:

8

Voici quelques conseils et pièges que j'ai recueillis après avoir utilisé le codage en direct pendant une semaine et après avoir parlé à un collègue.

A faire

  • Préparez un script à suivre et essayez de vous y tenir.
  • Videz fréquemment les tampons pour vous concentrer sur la partie pertinente.
  • Recommencez pour chaque nouveau sujet.
  • Utilisez une police plus grande.
  • Maîtrisez l'outil que vous utilisez pour éviter de perdre trop de temps sur des futilités.
  • Avoir des fonctions d'arrière-plan précodées. S'ils ne sont pas particulièrement pertinents, assurez-vous qu'ils peuvent être importés, plutôt que d'apparaître dans le fichier de travail.
  • Idéalement, travaillez dans une langue qui vous donne une rétroaction immédiate. Les langues avec un shell interactif sont les meilleures à cet égard.
  • Lorsque vous utilisez un type, indiquez le type attendu de la fonction que vous écrivez. Cela fournit une lumière de guidage pour les étudiants.
  • Faites librement des erreurs (mais pas trop). Expliquez comment ceux-ci doivent être corrigés.
  • N'oubliez pas - une image vaut mille mots: les diapositives entrelacées et le tableau noir / blanc fonctionnent avec votre session de codage.
  • Avoir des diapositives récapitulatives pour les points que vous avez couverts
  • Parfois, lors de la modification du code, faites peut-être une copie et modifiez la copie. Cela fournit un point de comparaison.
  • Nettoyez régulièrement le code.
  • Acceptez que vous fassiez des erreurs et permettez ouvertement aux élèves de vous corriger --- cela rend votre travail plus facile et les responsabilise.
  • Écrivez le code dans votre propre style. Par exemple, vous avez peut-être copié le code ailleurs. Mais cela sera difficile à reproduire. Mieux vaut l'écrire dans votre propre style. Par exemple, j'écris toujours des fonctions au curry, car je programme principalement Haskell. Mais Standard ML utilise moins fréquemment l'idiome. Attendre des fonctions au curry est l'erreur la plus courante que je fais en classe.
  • Physiquement, assurez-vous que votre espace est bien configuré. Bon clavier, à la bonne hauteur, câbles tous aux bons endroits, obstacles physiques à l'écart, etc. Prenez une minute avant de commencer à faire travailler votre espace pour vous, pas contre vous.
  • Une approche consiste à écrire tout ce que les élèves disent, même si c'est faux. Cela permet aux étudiants de faire le codage et la correction. C'est une bonne idée de nettoyer le code à la fin. Cette approche peut créer un modèle d'attention et d'interaction en classe, car les élèves doivent faire attention à suivre ce qui se passe.

À NE PAS FAIRE

  • N'optimisez pas votre code à la volée et ne le cassez pas de telle manière que vous ne puissiez pas le corriger.
  • Évitez de parler à l'ordinateur. Parlez aux étudiants!
  • Évitez de trop taper, en particulier de code passe-partout. Utilisez votre environnement pour vous aider à cracher les modèles pour vous.
  • Si vous utilisez un éditeur de texte, évitez de faire défiler constamment. Cela causera le mal des transports à ceux qui essaient de suivre.
  • Si vous utilisez un éditeur de texte, avant d'apporter des modifications radicales à votre code, avertissez les élèves que vous allez le faire, afin qu'ils puissent suivre ce qui se passe.
Dave Clarke
la source
1
Combien d'élèves sont dans ta classe? J'aime vos DO vers l'interactivité, mais je me demande comment cela évolue jusqu'à 50, 100, 250 étudiants.
Raphael
1
Publiez-vous votre code après le cours? J'imagine un référentiel Github où les étudiants peuvent parcourir les différentes versions que vous avez créées (y compris peut-être une version polie et commentée qui n'est jamais apparue en classe) et regarder les différences. Ils peuvent également cloner le référentiel pour utiliser facilement des algorithmes une fois écrits comme sous-programmes dans leurs devoirs (si cela est souhaitable).
Raphael
1
Préparez-vous des tests unitaires pour exécuter votre code? Je ne sais pas si c'est approprié dans chaque classe (l'accent est-il mis sur l'apprentissage des principes des langages de programmation, du développement de logiciels ou des algorithmes?), Mais cela pourrait enseigner quelques bonnes pratiques en cours de route.
Raphael
2
1) 128 personnes se sont inscrites à la classe, bien qu'environ 60 à 80 se soient présentées. 2) J'ai déjà le code sur les diapositives, mais je n'utilise pas les diapositives. Les élèves ont donc une version de ce que je fais, jamais aucune des étapes intermédiaires. Je ne sais pas vraiment à quel point il est intéressant d'avoir toutes les variantes. 3) Non, je ne le fais pas, bien qu'ils écrivent des spécifications informelles. L'accent est mis sur l'apprentissage d'un premier langage de programmation et de certains algorithmes / structures de données. Je suis d'accord cependant. Les tests unitaires sont quelque chose que nous envisagerons d'intégrer plus fortement dans le cours. Merci pour les questions / conseils implicites.
Dave Clarke