Write fewer, better notes: in your own words, with a small example you ran yourself and the mistake you made. Then test yourself instead of rereading, revisit topics on a spacing schedule and use what you learned in a project. Remembering comes from retrieval and use, not from how neat your notes look.
What people tell me
I study programming regularly and take a lot of notes, sometimes copying whole sections from courses. A few weeks later I have forgotten most of it and have to relearn the same topics. When I reread my notes they feel familiar, but when I try to write the code myself I cannot remember how. I have tried different apps and note systems, but nothing seems to help me actually retain what I learn.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Copying course material into notes feels productive but creates familiarity, not memory.
- Good programming notes are short, in your own words, with a small example you ran and the mistake you made.
- Testing yourself, by rebuilding from memory, beats rereading by a wide margin.
- Revisit topics on a spacing schedule, such as after one day, one week and one month.
- Using a concept in a real project is the strongest way to remember it.
Why your notes are not helping
When you copy sections from a course into your notes, you are doing two things: moving text from one place to another, and making it look familiar. Later, rereading those notes feels like knowing, because you recognise everything. Then you try to write the code alone and it is gone.
That feeling of familiarity is the trap. Recognising something and being able to produce it are different skills, and programming needs the second one. So the goal of notes is not to store everything. It is to help you retrieve and use what matters.
What a good programming note looks like
| Weak note | Strong note |
|---|---|
| Copied paragraph explaining closures | Two sentences in your own words: what a closure is and when you would use one |
| Code block pasted from the course | A tiny example you wrote and ran yourself |
| Every point from a two-hour video | The three things that surprised you or that you got wrong |
| No link to anything you built | A pointer to where you used it in your project |
| Neat formatting and colours | A question you can test yourself with later |
A strong note for one concept can be five to ten lines. Most of the value is in the example you ran and the mistake you recorded, because that is what you will actually need at work.
A simple template
Use the same shape for every concept:
- Concept: the name, for example "JavaScript promises".
- In my words: one or two sentences.
- Example I ran: the smallest working piece of code.
- Mistake I made: what broke and why.
- Where I used it: a link to the project or file.
- Test question: something like "Write a function that fetches two URLs and waits for both."
Point 6 is what turns notes into practice. When you revisit, answer the question from memory before looking at anything else.
Retrieve, do not reread
The single most useful change most people can make is to replace rereading with self-testing.
- Close your notes and the course.
- Try to rebuild the example or answer the test question from memory.
- Check against your notes only after you have tried.
- Fix the note if it was unclear, and mark the topic as weak or solid.
This feels harder and slower than rereading, which is exactly why it works. Struggling a little to recall something makes it stick much better than recognising it again.
Space your reviews
Memory fades on a curve. Revisiting just as you are starting to forget is far more efficient than cramming. A simple schedule:
| Review | When | What to do |
|---|---|---|
| First | Next day | Answer the test question from memory |
| Second | After about a week | Rebuild the example without looking |
| Third | After about a month | Use the concept in a slightly different problem |
| Later | Only if it was weak | Repeat the cycle for topics you missed |
You can keep this in a spreadsheet, a notes app with dates, or flashcards for small facts like syntax and command flags. Keep flashcards for facts; use rebuilding for concepts.
Use it in a project
Nothing locks in a concept like needing it to make something work. Every week, pick one or two things you learned and put them into your current project, even in a small way. If you learned about indexes, add one to a slow query. If you learned error handling, go back and handle errors properly in one feature. When should I stop taking courses and start building? explains why building earlier makes the learning stick.
Teach it
Explaining a concept, to a friend, in a short post or just aloud to yourself, quickly shows you what you do not understand. If you cannot explain it simply without your notes, that is a topic to review. Writing a short explanation publicly also builds a record of your learning that others can see.
A four-week reset
| Week | Focus | Output |
|---|---|---|
| 1 | Stop copying. Rewrite notes for your last five topics using the template | Five short notes, each with an example you ran and a test question |
| 2 | Daily 10-minute self-test on yesterday's topic before new learning | Seven retrieval sessions; weak topics marked |
| 3 | Start spaced reviews; add one learned concept to your project | A review schedule and one project change |
| 4 | Explain two topics aloud or in writing without notes | Two explanations, plus a list of gaps to fix |
Choosing a tool
Any tool works: paper, a plain text folder, a notes app, or notes inside your project repository. Choose one and stay with it. Switching between note apps is one of the most common ways to feel productive while learning nothing. If you are unsure, a folder of Markdown files kept with Git is simple, searchable and lasts forever.
Common mistakes
- Taking notes on everything. Write down what surprised you or what you got wrong, not the whole lesson.
- Rereading as revision. It feels good and does very little.
- Beautiful notes, no code. Formatting time is not learning time.
- Never revisiting. Notes you never test yourself on are an archive, not a memory aid.
- Learning without using. If a concept never appears in anything you build, it will fade.
If you are still stuck
If you keep losing progress because your learning feels scattered, How can I tell whether I am actually improving? gives you a way to measure it, and What to do when you are stuck learning to code covers the other common causes. For a structured path that tells you what to learn and when to revisit it, join Sefism. It is free to learn, you get credits on joining and your first roadmap is free. Members can also ask their own question about their study system.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.