You finish a book, underline the important parts, and feel that you understand it. Months later, someone asks you to explain an idea from it. You remember where it was on the page. The explanation is much harder to find.
That frustration is why Titus started Restudium. Excellent books were getting read, but too little of their knowledge was available later. A shelf of finished books was a poor substitute for understanding he could use.
For a book you want to learn from, build a small system around the reading: understand an idea, attempt to explain it with the book closed, check your answer, and return after some time has passed. The system needs to be manageable enough to repeat.
Decide what you want to carry with you
You do not need to memorize every sentence. Before a chapter, ask what it might help you explain or do. A book about software design might help you reason about responsibilities between modules. A chapter about probability might help you recognize when a conclusion rests on a small sample.
Choose a few ideas that support that goal. Prefer mechanisms, relationships and useful distinctions over incidental names or numbers. Keep the author's caveats with the idea. Remembering a rule while forgetting when it applies can leave you confidently wrong.
Read far enough to understand the explanation before turning it into a check. If the passage assumes something you do not know, resolve that first. Trying to recall an unexplained term is a frustrating way to begin.
Close the book before explaining
Highlighting makes a useful passage easier to find. Notes can hold your questions and connections. Give those tools a second job: use them to prepare a question you can answer without looking at the source.
Suppose a chapter explains caching. A cache stores a copy so that a future request can avoid repeating some work. The copy can become stale if the original changes. After reading the explanation, close the book and try this:
A café prints tomorrow's menu tonight. In the morning, the kitchen runs out of an ingredient and changes the live menu. Why can the printed copy now mislead a customer? What would need to happen to make it reliable again?
A useful answer identifies the copy, the changing source and the missing update. It might propose replacing the printed menu or checking the current one. That tells you more about your understanding than recognizing the definition of a cache.
In Roediger and Karpicke's 2006 experiments, students who practiced retrieving studied passages did better on delayed recall tests than students who spent the corresponding practice time restudying. The work supports making retrieval part of study; it does not supply a universal retention percentage for every book or learner.
Compare the reasoning, then repair it
Write or say an answer before revealing the explanation. Then look for the important pieces. Did you explain why the problem happens? Did you state an assumption? Did your proposed solution actually address the cause?
In the menu example, “print it more neatly” would not fix stale information. If your answer missed the update, return to that part of the explanation and reconstruct the sequence. Try a different case next time, such as a saved timetable after a train cancellation.
An answer does not have to match the author's wording. It does need to preserve the meaning. Keep a source reference so that uncertainty can send you back to the actual explanation, rather than to a growing pile of unverified notes.
Give the idea another day
A reading session needs a route back. Dunlosky and colleagues' review of learning techniques rated practice testing and distributed practice highly across the evidence it examined. Repeated study can include both: attempt recall, and spread those attempts over time.
For a simple manual routine, put a few questions somewhere you will revisit. Try them on a later day; revisit difficult ideas sooner and leave a longer gap after a sound answer. These are practical starting points, not a scientifically optimal schedule. The material, your prior knowledge and how long you need to retain it all matter.
Keep the questions small enough that you will actually attempt them. If every review asks for a whole chapter summary, a busy day can turn into a reason to avoid the entire system.
Make consistency part of the design
A workable sitting might be a few older questions followed by one new idea. Choose a regular opportunity to study, leave a clear next step, and finish while the workload still feels manageable. After a missed day, resume with a bounded session. You do not need to punish yourself with a marathon.
For interview preparation, add practice explaining aloud and responding to a changed assumption. For deeper understanding, connect the idea to another chapter or a problem you have encountered. Remembering a term, explaining its mechanism and using it under pressure are different tasks.
Restudium brings this practice into a learning system for software engineers. Clear teaching leads into a check, earlier ideas return for spaced review, and progress records what you've worked through. The private beta starts with one reviewed book course and a bounded sitting: a new idea or chapter test, plus up to three due reviews. The aim is a routine you can sustain and understanding you can use later.