You can follow every line of a worked math problem, lab calculation, grammar exercise, or coding example—and then face a nearly identical question alone and have no idea where to begin. The problem is not necessarily that you “didn’t understand.” It is that the page was doing too much of the thinking for you.
A completed example is valuable because it shows the shape of good work. But reading it straight through creates a smooth, misleading experience: each next step looks obvious after someone has supplied it. To make an example teachable, you need to interrupt that smoothness and repeatedly ask your brain to supply a small missing decision.
This method turns a model solution into a series of short practice attempts. It is especially useful when a class gives you a solved problem but not enough feedback to tell whether you could reproduce the reasoning independently.
First, identify what the example is actually teaching
Before covering any lines, look at the finished example once and name its central job. Do not settle for a broad label such as “solve equations” or “write an analysis.” Be more concrete.
- In algebra, the job might be choose an equation from the word problem, then isolate the unknown without changing the equality.
- In chemistry, it might be convert each given quantity to moles before comparing a reaction ratio.
- In essay writing, it might be turn an observation from a passage into a claim, then explain why the wording supports that claim.
- In programming, it might be trace the input through a loop and update one variable at a time.
This matters because an example often contains several kinds of information at once: the main technique, formatting conventions, vocabulary, arithmetic, and comments about common errors. If you try to learn all of it as one unbroken performance, you will not know what caused trouble later.
Mark the decision points, not every line
Read the model and put a small mark beside places where the solver had to choose something. These are usually moments such as:
- selecting a formula, rule, or strategy;
- deciding what information matters;
- rearranging an expression or sentence;
- checking whether an answer makes sense;
- explaining why a piece of evidence supports a conclusion.
Do not mark mechanical steps just because they look complicated. A long multiplication step may deserve practice, but it is different from the earlier decision to use multiplication at all. Separating those jobs makes your review more precise.
A worked example becomes useful practice only when you make some of its invisible choices visible—and then try making them before looking.
Use the cover-and-complete pass
Now work through the example again, but conceal a small amount at a time with a sheet of paper, a sticky note, or a folded screen. Your goal is not to recreate the whole solution from memory on the first pass. Your goal is to predict the next meaningful move.
- Read up to a decision point. Stop before the model reveals what it does next.
- Say or write your prediction. A brief note is enough: “Define the variable,” “convert grams to moles,” “use this quote to establish contrast,” or “test the loop with the first list item.”
- Reveal only the next step. Compare your move with the model’s move.
- Explain the connection. Ask, “What feature of the problem made this step appropriate?”
- Continue in small sections. Keep the hidden portion short enough that you are practicing a decision rather than guessing an entire page.
If your prediction differs from the model, do not automatically label it wrong. Ask whether it would still work. Some tasks allow multiple valid routes. If your route is valid but less efficient or less clear, note that distinction. If it would fail, identify the exact missing condition. “I forgot the units” is more useful than “I messed up.”
Write the reason beside the step
Many examples tell you what happened but leave the reason implied. Add a short reason in your own words beside the most important steps. Keep it tied to the evidence on the page.
For instance, instead of copying “divide both sides by 4,” write “the variable is multiplied by 4, so undo that operation on both sides.” Instead of copying “this quotation shows the narrator is uncertain,” write “the repeated ‘maybe’ weakens the claim and signals doubt.”
Your explanation does not need polished prose. It needs to be specific enough that you could use it on another problem tomorrow.
Make a one-line trigger for the method
Once you have completed a model, compress its main reasoning into an if-then trigger. This gives you something usable when a fresh problem does not come with helpful annotations.
A trigger has two parts: the clue you notice and the response it calls for.
- If quantities are given in different units, then convert them before comparing or combining them.
- If a question asks what a source implies, then state the implication and point to the wording that led there.
- If a function’s output changes in a repeating pattern, then check a few inputs and look for the operation that repeats.
- If a prompt has two required ideas, then plan a separate sentence or section for each before drafting.
A trigger is not a magic rule for every situation. Its purpose is to preserve the useful cue from the example. When you get stuck, it gives you a first question to ask rather than a full solution to imitate.
Test whether you learned the reasoning, not the page layout
The real test comes after you put the original aside. Create a nearby problem: same core method, changed surface details. You can often make one from your course material without inventing a complicated new assignment.
Change one feature at a time. In a calculation, use different numbers or reverse which quantity is unknown. In a language exercise, choose a new sentence with the same grammar pattern. In an essay model, use a different passage and make the same type of claim. In code, change the input while preserving the program’s task.
Then begin with a blank page. Do not keep the model in your peripheral vision. If you need help, return to your one-line trigger first, not the completed answer.
Use a three-level check
After your new attempt, check more than whether the final answer matches.
- Choice: Did I choose an appropriate method?
- Execution: Did I carry out the steps accurately?
- Explanation: Could I say why the method fits this problem?
This distinction prevents an unhelpful conclusion. A correct answer reached by lucky guessing needs a different response than a wrong answer caused by a small arithmetic slip. The first calls for clearer reasoning; the second may call for a slower checking routine.
What to do when the model feels too advanced
Sometimes a worked example skips several steps because the instructor expects prior knowledge. Covering and predicting will reveal the gap, but it cannot fill a prerequisite you have not learned yet.
When that happens, shrink the task. Identify the first line that stops making sense and write a question with a narrow target: “Why was this variable introduced here?” “How did this term disappear?” “What does this command return before the next line runs?” This is much easier to resolve with class notes, a textbook section, a teacher, or a tutor than “I don’t get the example.”
It also helps to separate unfamiliar vocabulary from unfamiliar reasoning. Look up or clarify the term first if the term is blocking the logic. But do not spend an hour rewriting definitions when the real issue is choosing a method.
Common ways this method goes wrong
Covering too much too soon
If you hide an entire solution and cannot start, the practice chunk is too large. Reveal the problem setup and try only the first decision. Independence is built in increments.
Copying explanations word for word
Copied commentary can look like understanding because it sounds polished. Replace it with a short, plain-language reason. Awkward but accurate wording is more useful than an elegant sentence you cannot reconstruct.
Practicing only the example’s exact numbers or wording
Recognition thrives on familiar details. A small change exposes whether you learned the relationship underneath. Keep the skill the same while changing the context.
Treating every difference as an error
In writing, coding, and many multi-step problems, the model is often one good route, not the only possible route. Compare your work for validity, clarity, and whether it meets the task—not for visual resemblance alone.
An illustrative five-minute study cycle
Suppose a biology worksheet includes a model that uses a graph to explain how one variable changes as another changes. An illustrative short cycle might look like this:
- Read the prompt and model introduction. Identify the central job: describe the relationship and support it with graph details.
- Cover the model’s first claim. Write your own claim from the overall trend.
- Reveal the claim and compare it with yours.
- Cover the evidence sentence. Choose two specific graph features that support the claim.
- Write a trigger: “When explaining a graph, state the overall trend, then name the plotted details that show it.”
- Use the trigger on a second graph from the same chapter without looking back.
Notice that this does not require making a giant study guide. It asks you to practice the moment that matters: turning visible information into an appropriate next move.
Keep one reusable record
At the bottom of your notes, leave three lines for each important model:
- Problem clue: What tells me this method may apply?
- First move: What do I do before the work branches into details?
- Check: What would show that my answer or reasoning is plausible?
Over time, these lines become a compact decision guide. They are more useful before a quiz or assignment than pages of copied solutions because they point you toward choices rather than displaying outcomes.
Next action: Choose one worked example from your current course. Mark three decision points, cover the next step at each one, and write a one-sentence trigger before you move on to anything else.