End of the week
I record one strong piece of evidence, one recurring error, one thing I need support with and one next task.
I record the question I asked, what I produced, where it failed and what I changed in the second version. The template I use is below, with one example.
This is not a diary about everyday personal detail. It is a working tool that shows why I decided something in a lesson, a project or a piece of research, what evidence changed a conclusion, and whether the same error returned.
Writing “I studied Python today” does not explain my progress. Instead I write down the question, my initial expectation, what I produced, the test, the error, the feedback, the change and the next step. The same structure can be used for coding, electronics, research, sport data or school subjects.
Every entry gets the same eight fields.
| Field | What I ask myself | Example |
|---|---|---|
| 1. Date and topic | What did I work on? | Sensor threshold |
| 2. Question | What uncertainty am I trying to resolve? | Why does the count rise with no movement? |
| 3. Initial expectation | What did I think would happen? | The threshold may be too low |
| 4. Artefact | What did I build or write? | A ten-reading test script |
| 5. Evidence | What did I observe or measure? | Three false counts while still |
| 6. Error | Which assumption failed? | One threshold did not fit every condition |
| 7. Change | What changed after feedback? | Added a time window and a second check |
| 8. Next step | What is the next small test? | Try different movement speeds |
Imagine a movement sensor that counts whenever its value crosses a threshold. In the first test the threshold is set low, so counts appear even while the device rests on a table.
The second version checks two conditions across a short time window instead of a single instant reading. False counts fall, but some slow movements may be missed. Instead of writing only “fixed”, I record both the false counts and the missed movements. The decision then rests on measurable change rather than one successful demonstration.
If I clean an error log up to make it look perfect, the strongest learning evidence disappears. The aim is not to create failure, but to reproduce it safely and explain its cause.
I record one strong piece of evidence, one recurring error, one thing I need support with and one next task.
I look across four weeks for questions and error types that repeat.
I select the two most meaningful pieces of work together with their first and final versions.
I choose the goal from a gap in the evidence rather than from a vague result target.
A useful entry does not need to be long; it needs to make the decision traceable. If another person can understand why my first expectation changed and which question the second test addressed, the entry is doing its job.
Collecting numerical data alone is not enough either. If I do not state the limits of the measuring tool, the number of observations, the conditions and how I observed, a detailed-looking table can create false certainty.
Entries are not given a performance score at month end. Instead, recurring errors, frequently used sources, points where help was needed and the number of second versions are reviewed. The point is not to create pressure to appear productive but to improve the way I learn.