Apprendre à programmer avec des flashcards : les cartes vraiment utiles

Pour apprendre à programmer avec des flashcards, utilisez-les dans trois cas : les concepts que vous devez savoir expliquer, la syntaxe que vous recherchez chaque semaine et les courts extraits de code dont vous prédisez la sortie. Le reste de l’apprentissage se fait en écrivant des programmes, en vous trompant et en déboguant. Les flashcards soutiennent cette pratique ; elles ne la remplacent pas.

La raison est simple : programmer est une compétence de production. Reconnaître une fonction dans un tutoriel ne signifie pas que vous savez l’écrire face à un éditeur vide. Pourtant, chaque fois que vous interrompez un exercice pour chercher comment parcourir un dictionnaire, vous perdez le fil. C’est exactement ce genre de petit fait récurrent qui a sa place sur une carte.

Se limiter à quelques formats rend le paquet facile à réviser et à corriger. Ces trois-là couvrent presque tout ce qui mérite d’être retenu sans recherche.

Première carte : si a = [10, 20, 30, 40, 50], que renvoie a[1:3] ? Réponse : [20, 30]. La tranche commence à l’indice 1 (le deuxième élément, puisqu’on compte à partir de 0) et s’arrête avant l’indice 3. Deuxième carte : avec x = [1, 2] et y = [1, 2], que donnent x == y et x is y ? Réponse : True et False. L’opérateur == compare les valeurs ; is vérifie si les deux noms désignent le même objet, et ici ce sont deux listes distinctes au contenu identique.

Troisième carte : qu’affiche for i in range(3): print(i) ? Réponse : 0, 1 et 2, chacun sur sa propre ligne, car range(3) commence à 0 et s’arrête avant 3. Avant d’enregistrer une carte de ce type, exécutez l’extrait et copiez la sortie réelle. Ainsi, vous ne mémoriserez jamais une réponse fausse tapée de mémoire.

Le cycle qui fonctionne le mieux associe un projet et des cartes. Vous construisez quelque chose de petit, par exemple un script qui lit un fichier de notes et calcule des moyennes. Chaque fois que vous devez chercher quelque chose, vous le notez. À la fin de la séance, vous transformez deux ou trois de ces notes en cartes et laissez de côté celles dont vous n’aurez plus besoin.

Ainsi, le paquet reflète vos vraies difficultés plutôt que toute la documentation du langage. Au bout de quelques semaines, vous chercherez moins et consacrerez votre attention à la logique du problème. Quand une carte a passé un mois sans erreur et que vous utilisez cette notion avec aisance dans vos projets, arrêtez d’en ajouter des variantes.

Kornell (2009) a comparé deux façons d’étudier des flashcards de vocabulaire : un grand paquet dans lequel chaque carte revenait après beaucoup d’autres, et plusieurs petits paquets révisés par séances concentrées. La révision espacée a donné un meilleur rappel chez la plupart des participants, alors que beaucoup pensaient que le bachotage leur réussissait mieux. L’étude portait sur des mots, pas sur du code, mais la leçon sur l’espacement s’applique à tout fait que vous devez retenir.

En pratique, dix minutes de cartes par jour valent mieux qu’une heure le dimanche. Quand vous apprenez un nouveau langage, ajoutez quelques cartes par séance et laissez revenir les plus anciennes avant d’en ajouter d’autres.

Roediger et Karpicke (2006) ont constaté, avec des textes en prose, que les étudiants qui se testaient retenaient davantage une semaine plus tard que ceux qui réétudiaient. Appliqué à la programmation : écrivez une fonction que vous avez déjà résolue, sur papier ou dans un fichier vide, sans regarder la solution, puis exécutez-la. Les erreurs qui apparaissent constituent votre liste de révision.

Un autre test utile consiste à expliquer à voix haute ce que fait chaque ligne d’un extrait avant de l’exécuter. Si vous ne savez pas dire pourquoi une variable change de valeur, vous ne comprenez pas encore le code, même si le programme fonctionne. Cette explication révèle des lacunes qu’une carte de syntaxe ne montrera jamais.

Les flashcards de programmation échouent toujours pour les mêmes quelques raisons. Passez votre paquet en revue toutes les quelques semaines avec cette liste en main.

Dans Lumia AI, vous pouvez créer un livre par langage ou par cours et le diviser en blocs ou en neurones, par exemple types de données, fonctions et gestion des fichiers. Rédigez vos cartes à la main avec de courts extraits, ou générez un brouillon à partir de vos notes ou d’un PDF de la documentation de votre cours ; exécutez chaque exemple avant de l’accepter, car un brouillon peut contenir une sortie erronée.

Pendant la révision, évaluez chaque carte avec À revoir, Difficile, Bien ou Facile, et Lumia planifie la révision suivante. Un quiz avec des questions Mettre dans l’ordre vous aide à travailler l’enchaînement des étapes d’un algorithme. Lumia n’exécute pas de code : les vrais tests restent dans votre éditeur.