Article original : How not to run a Learn-to-Code Bootcamp
Par Michelle Jones
L'histoire que vous allez voir est vraie ; les noms ont été changés pour protéger les innocents.
_Code Python par [nyuhuhuu](https://www.flickr.com/photos/nyuhuhuu/4653088356" rel="noopener" target="blank" title=").
Avant le début du cours
_[Publicité de 1919 pour une école de formation Comptometer](https://commons.wikimedia.org/wiki/File:Comptometer_ad_1919.png" rel="noopener" target="blank" title=").
Ne pas identifier votre public cible
Envoyez la page d'inscription à tous les abonnés qui vous ont déjà donné leur adresse e-mail. Vous n'avez aucune information sur leur parcours ou leurs intérêts ? Peu importe, votre cours est SUPER IMPORTANT. Il serait totalement négligent de votre part de ne pas informer les centaines de personnes qui ont déjà entré leur adresse e-mail sur votre site.
Ne pas mentionner le contenu du cours
Qui n'aime pas un mystère ?
Ne donner aucune indication sur les compétences préalables
Laissez le mystère continuer en fournissant uniquement des suggestions vagues sur la quantité de programmation préalable que les gens devraient avoir, et des suggestions vagues sur les langages précédents qui pourraient être utiles.
Ne couvrez rien sur les types de programmation que les gens devraient avoir faits.
Devraient-ils être familiers avec l'écriture de fonctions ? Si oui, à quel point compliquées ? Peu importe ?
Ne fournir aucune information sur l'engagement en temps
Encore une fois, ne gâchez pas le mystère ! Tout le monde qui s'inscrit à un bootcamp a beaucoup de temps à perdre. Par conséquent, cette information est complètement irrelevante.
Une fois le cours commencé
Impression sur la console
Il est obligatoire que le code initial du premier jour imprime un message sur la console. Soyez novateur ! Faites-les imprimer autre chose que "Hello world".
Il est extrêmement important pour les programmeurs de savoir comment imprimer uniquement le texte qu'ils ont fourni dans la commande d'impression.
Ne mettez surtout pas l'accent sur la façon d'incorporer les résultats de leur code dans cette commande d'impression dès le premier jour. Enterrez cette information.
Enterrer les informations clés de syntaxe
Il y a plusieurs morceaux d'information qui peuvent être enterrés !
Les étudiants doivent apprendre à lire chaque phrase de votre leçon attentivement. Par conséquent, ne placez pas les points clés de syntaxe tout en haut, au début de la leçon 1.
Au lieu de cela, enterrez cette information à mi-chemin de la leçon 1. La syntaxe est beaucoup moins importante que d'apprendre à imprimer "Hello world" sur la console. Elle est également beaucoup moins importante que d'apprendre que + est l'opérateur d'addition.
Placez vos leçons et vos exercices sur deux écrans séparés
Apprendre à utiliser deux écrans est une compétence que les programmeurs doivent éventuellement apprendre. Comment mieux leur enseigner qu'en séparant les leçons et les exercices ? Je veux dire, les livres ont tendance à avoir des exercices à la fin de chaque chapitre. Le modèle du livre est super important à utiliser dans les cours en ligne.
Titres, schmitres
Lorsque vous enseignez aux gens comment coder, n'utilisez pas de titres pour chaque sous-section dans une leçon. L'expérience d'apprentissage est améliorée en faisant défiler les étudiants vers l'avant et vers l'arrière. Plus la page de leçons est longue, mieux c'est ! Il y a toujours l'option "Rechercher" dans leur navigateur !
Points bonus : utilisez parfois des titres, et parfois non.
Indices et solutions
Les indices et solutions qui sont commentés sont utiles pour les étudiants. Nous sommes parfois un peu bloqués sur pourquoi notre code ne fonctionne pas. Si nous sommes vraiment bloqués, nous pouvons voir comment notre code diffère de la solution.
Cette expérience est améliorée en s'assurant que les indices et solutions retournent des erreurs lorsqu'ils sont exécutés par les étudiants. Ignorez les commentaires des étudiants qui mentionnent que les indices et solutions ne fonctionnent pas.
Ceci est particulièrement important dans un bootcamp, où les étudiants ont une leçon différente chaque jour, et les indices et solutions ne sont pas corrigés avant la leçon du lendemain.
Pénalisez les étudiants pour leur créativité
Il n'y a qu'une seule façon d'écrire du code. Utilisez des exemples qui encouragent à réfléchir sur les entrées fournies par l'utilisateur. Ne dites pas à vos étudiants comment obtenir les entrées fournies par l'utilisateur. Enterrez le code sur la façon de générer des nombres aléatoires (qui peuvent être utilisés pour le débogage) dans des exercices marqués comme difficiles.
N'anticipez pas que l'utilisateur est bon avec Googlefoo. Évidemment, parce qu'ils ont une certaine expérience de programmation préalable, ils n'ont jamais utilisé Google pour localiser des exemples de code.
Mais supposez qu'ils ont Googlefoo pour comprendre comment créer des nombres aléatoires pour tester leur code. Ou qu'ils lisent l'intégralité des exercices marqués comme particulièrement difficiles.
Permettez à leur code de s'exécuter parfaitement sur leur page de leçons. Ensuite, après que l'étudiant a commis le code et que le code est public, affichez de grosses erreurs.
C'est de leur faute, ils auraient dû regarder l'indice. Ils auraient pu simplement utiliser la solution s'ils étaient vraiment bloqués.
Obtenez les retours sur le cours dès le premier jour
Tout le monde sait que la première leçon est le moment idéal pour obtenir les retours des étudiants. La première leçon est la plus difficile. Combien d'étudiants peuvent épeler correctement "Hello world" ? De plus, l'algèbre de base est très compliquée pour les programmeurs venant à un nouveau langage.
Le rebondissement mystérieux
J'ai abandonné après le deuxième jour.