How to remember what you read, especially the docs

By Artem Markovskyi, the maker of Nano Learny · September 2026 · About 7 minutes

You spend an evening with the docs of a framework your team is adopting. It all makes sense. You nod along, try a couple of examples, close the tab. Three weeks later you need it, and you’re back on the same page, reading it as if for the first time.

That isn’t a lack of discipline. It’s how memory works when the only thing you did was read. The good news is that the fix is small, well understood, and fits in a few minutes a day. This is the method I use, and the reason I ended up building an app around it.

Can you remember everything you read?

No, and you don’t need to. Documentation is a reference; most of it is meant to be looked up. What you want to keep is the layer underneath: the concepts, the mental model of how the pieces fit, the defaults and gotchas that bite, and a map of where the details live. If you remember those, the docs become fast to use instead of something you reread.

So the real question is how to remember what matters from what you read. That part is very doable.

Why rereading doesn’t work

Memory fades fast after a single exposure. Hermann Ebbinghaus charted this in the 1880s as the forgetting curve: without review, much of what you learn slips away within days, and it fades fastest right at the start.

The usual response is to reread, and rereading has a trap in it. The second time through, the text feels familiar, and familiarity feels like knowing. But recognizing an idea when it’s in front of you is a different skill from producing it when it isn’t. Your job asks for the second one: in a code review, in a design discussion, at 2 a.m. during an incident. Nobody hands you the paragraph.

Highlighting has the same problem. It marks what seemed important, but it doesn’t make you do anything with it.

What works instead

Two findings from learning research have held up for decades and show up in most books on the subject.

1. Retrieval practice: answer questions instead of rereading

Pulling something out of memory strengthens it more than putting it in again. Researchers call it the testing effect, although it has nothing to do with grades: a question you answer from memory, even badly, does more than another read of the page. Getting an answer wrong and then seeing the right one is part of how it works, not a failure.

2. Spacing: review just before you forget

The same review is worth more if you wait. Answering a question an hour after reading is easy and does little; answering it a few days later, when it takes some effort, does a lot. Each successful recall after a gap makes the next gap longer. That’s the whole idea behind spaced repetition apps like Anki.

Put together: read once, then turn what you read into questions, and answer those questions a few times over the next weeks, with growing gaps. That’s it. The rest is making it easy enough that you actually do it.

A method for reading docs and retaining them

Read with a question in mind

Before you open a page, write down what you want to be able to do or explain afterward. “When does an effect run, and how do I stop it running on every render?” gives your reading a target and tells you when you’re done.

Turn each section into two or three questions

After each section, stop and write a couple of questions with their answers. The best ones make you predict, compare or explain, not just define:

• Predict: “In Python, what does [] or "default" evaluate to?” ("default": an empty list is falsy.)
• Compare: “What’s the difference between git reset --soft and --mixed?” (Both move the branch; --soft keeps your changes staged, --mixed unstages them.)
• Gotcha: “Does a plain CREATE INDEX in PostgreSQL block writes to the table? What’s the alternative?” (It does; CREATE INDEX CONCURRENTLY avoids that, at the cost of a slower build.)
• Explain: “Why does React ask for a key on list items?” Answer in one sentence of your own.

Skip trivia. You don’t need a question for every parameter. Ask about the things you’d be embarrassed to get wrong, or that cost you an hour last time.

Close the tab and answer

Right after reading, answer your questions without looking. Say the answer out loud or type it, then check. The ones you miss are the most valuable ones you have; mark them.

Space the reviews

Answer the same questions again tomorrow, then a few days later, then a week or two after that. The exact schedule matters much less than doing it at all. Drop a question once it’s easy several times in a row; keep the ones that still trip you up.

Keep it small and daily

Five minutes every day beats a two-hour Saturday you don’t repeat. After a full day of work, a big study session rarely happens, but a few minutes can: on the commute, while the coffee brews, while a build runs. Tie it to something you already do every day and it stops needing willpower.

Then use it

Questions keep the knowledge alive; building with it is what makes it yours. The two work together. Recall means that when you sit down to build, you already know what the tool can do, and building shows you which questions you should have asked.

Tools for it

You don’t need any. A plain notes file with questions and answers works, as long as you come back to it. Anki is the classic tool for spacing reviews out: you write the cards, it schedules them. The catch, and the reason most people give up, is the writing. Turning a long docs page into good questions takes longer than reading it.

If you want to go deeper into the research, Make It Stick by Peter C. Brown, Henry L. Roediger III and Mark A. McDaniel is a readable summary, and Michael Nielsen’s essay “Augmenting Long-term Memory” is a thoughtful account of using Anki for technical material.

Why I built Nano Learny

I kept up Duolingo for English for a year, one to three minutes every morning. It was an easy start to the day that needed little energy or willpower. A single day taught me little, but it added up, and it stuck.

I wanted the same for programming, to keep growing while AI and short-form content keep changing the field. Mimo worked as a habit, but the content was too easy for me, and the free version didn’t let me skip ahead. What I actually wanted was the official React docs as Duolingo-style lessons. The apps I found were built for students cramming before an exam, had too many features, or wrote weak lessons on developer topics.

So I built the thing I was looking for: the method above, with the slow part done for you. You paste a docs link or upload a PDF, and Nano Learny writes a course of three-minute lessons from it; for popular technologies, a ready-made one is waiting in the app. Every lesson ends in questions, and key facts from earlier lessons come back as review questions later, spread across the course. There’s a streak and a home-screen widget, because a habit needs a nudge, and there are no hearts or daily limits, because the habit is the point.

It’s not a replacement for building things, and it won’t teach you to program from zero. It’s for the part next to building: understanding the docs of the tech you use, and still knowing it a month later.

Also on this site: the best microlearning apps in 2026, compared for developers.