The fastest way to revise Computer Science is to find what you get wrong, name the reason, and retest it with a fresh question. Sorting mistakes by cause tells you what to practise, which a topic list alone cannot.
This page shows the method with a filled example. The mistake log and retest queue lets you keep the same kind of log privately in your own browser.
Why do notes and rereading stop working?
Rereading recognises an answer, while an exam asks you to produce one. You can read a trace table and follow every step, then freeze on a blank one. That gap only closes when you attempt the work.
So the plan is simple: attempt, check, log, retest. Keep the attempt short and the log shorter.
First, confirm the scope
Before revising, check that your list matches your syllabus code and exam year. Notation and language expectations can differ between routes. Use the syllabus and exam-year navigator and the study route guide to confirm it, and open the Cambridge page for the current details.
If an old video teaches a topic your syllabus does not list, put it aside rather than spending a week on it.
What should a mistake log record?
Use four columns:
| Question or task | What I did | Cause type | Next action |
|---|---|---|---|
| Where it came from | What I wrote or predicted | One of the four types below | A fresh task and a date |
Sort each error into one of four cause types:
- Slip: the method was right, a value was copied or updated wrongly.
- Interpretation: I misread what the question asked.
- Gap in reasoning: I did not know how to get from one step to the next.
- Term: I mixed up two words, such as validation and verification.
Worked example: five log entries
Here is an original log after one evening of mixed questions.
| Task | What I did | Cause | Next action |
|---|---|---|---|
| Trace a loop, 5 items | Stopped after item 4 | Gap in reasoning (off by one) | Retest: loop with 6 items |
| Trace a loop, sum | Wrote total before adding | Slip | Retest: fresh sum trace |
| Hex to denary | Used 10 for F | Slip | Retest: two fresh conversions |
| Explain verification | Described range checks | Term | Write both definitions with examples |
| Test data for a 1 to 20 input | Listed only 5, 10, 15 | Gap in reasoning (no boundaries) | Retest: list boundary data |
Count the causes: 2 slips, 2 gaps in reasoning, 1 term. So 4 out of 5 entries involve tracing or test data, which is where the next session should go.
That is a finding, not a verdict. The same student might have a very different pattern next week.
How do I schedule the retests?
For every entry, write a fresh task, not the same one. A fresh task tests the skill, while the same task only tests your memory of the answer.
A workable pattern: retest 1 to 2 days later, about a week later, then inside a mixed set. If the retest passes twice, retire the entry. If it fails again, move to a different explanation, for example from the terminology guide or a module lesson, before trying again.
Which practice goes with which gap?
- Tracing and loops: repetition and arrays and the loop help page.
- Test data: validation, verification and testing and the boundary case help page.
- Mixed questions with explained answers: original practice.
- Watching a trace run step by step: the pseudocode trace trainer, where your route allows it.
A common trap: revising the topics you already like
Most students start with the topics that feel comfortable, because success feels good. The log stops this by showing where errors really are. Check it before choosing what to revise next.
When to ask for help
Self-revision works when you can tell why an answer is wrong. If you retest an item three times and still cannot explain the error, that is a signal, not a failure. A teacher can ask you to talk through the step aloud and find the belief underneath.
Online one-to-one Computer Science tuition starts with a paid one-hour trial at the assigned teacher’s confirmed rate, from RM80. See the learning guide for the full topic map.