Learn programming with flashcards: the cards that actually help

To learn programming with flashcards, use them in three cases: concepts you need to explain, syntax you search for every week, and short snippets where you predict the output. The rest of the learning happens by writing programs, making mistakes and debugging. Flashcards support that practice; they do not replace it.

The reason is simple: programming is a production skill. Recognizing a function in a tutorial does not mean you can write it from an empty editor. Yet every time you stop an exercise to search how to loop over a dictionary, you lose your train of thought. That kind of small, recurring fact is exactly what belongs on a card.

Keeping only a few formats makes the deck easy to review and correct. These three cover nearly everything worth recalling without a search.

Card one: if a = [10, 20, 30, 40, 50], what does a[1:3] return? Answer: [20, 30]. The slice starts at index 1 (the second item, since counting starts at 0) and stops before index 3. Card two: with x = [1, 2] and y = [1, 2], what do x == y and x is y give? Answer: True and False. The == operator compares values; is checks whether both names point to the same object, and here they are two separate lists with the same contents.

Card three: what does for i in range(3): print(i) print? Answer: 0, 1 and 2, each on its own line, because range(3) starts at 0 and stops before 3. Before saving any card like this, run the snippet and copy the real output. That way you never memorize a wrong answer you typed from memory.

The loop that works best combines a project with cards. You build something small, such as a script that reads a file of grades and computes averages. Every time you have to look something up, you jot it down. At the end of the session, you turn two or three of those notes into cards and drop the ones you will not need again.

This way the deck reflects your real difficulties rather than the language's full documentation. After a few weeks you will search less and spend your attention on the logic of the problem. Once a card has gone a month without a miss and you use that fact comfortably in your projects, stop adding variations of it.

Kornell (2009) compared two ways of studying vocabulary flashcards: one large deck in which each card came back after many others, versus several small decks reviewed in concentrated bursts. Spaced review led to better recall for most participants, even though many believed cramming worked better for them. The study used words, not code, but the lesson about spacing applies to any fact you need to remember.

In practice, ten minutes of cards a day beats an hour on Sunday. When you learn a new language, add a few cards per session and let older ones come back before you add more.

Roediger and Karpicke (2006) found, using prose passages, that students who tested themselves remembered more a week later than students who restudied. Applied to programming: write a function you have already solved on paper or in an empty file, without looking at the solution, then run it. The errors that appear are your review list.

Another useful test is explaining out loud what each line of a snippet does before you run it. If you cannot say why a variable changes value, you do not yet understand the code, even if the program works. That explanation exposes gaps a syntax card will never show.

Programming flashcards fail for the same handful of reasons. Go through your deck every few weeks with this list in hand.

In Lumia AI you can create a book for each language or course and split it into blocks or neurons, such as data types, functions and file handling. Write your cards by hand with short snippets, or generate a draft from your notes or a PDF of your course documentation; run every example before accepting it, because a draft can contain a wrong output.

During review, rate each card Again, Hard, Good or Easy and Lumia schedules the next review. A quiz with Put in Order questions helps you practice the sequence of steps in an algorithm. Lumia does not run code: real testing stays in your editor.