How Education Works | Learning to Code in a New School: Algorithms, Debugging and Explaining Your Program

State what the program should receive, do and produce. Keep the requirement small enough to inspect. “Make a useful app” is too broad for a first transition check; “count how many supplied numbers are greater than ten” has a clear behaviour.

Identify conditions in the requirement. Greater than ten excludes ten itself. At least ten includes it. That language distinction changes the correct program and should remain visible before any code is written.

Ask the learner to describe an example result without using the editor. For the supplied values 9, 10 and 12, exactly one value is greater than ten. This checks understanding of the task before syntax becomes another demand.

Separate a working program from an appropriate program. A program can run successfully while solving a different question. The requirement gives testing a reference point beyond the absence of an error message.

Keep the intended behaviour beside the project. When a student moves from one language to another, this shared meaning can provide continuity. The representations may change while the question about input, decisions and output remains something the learner can explain and check.

Contents · Next chapter

Ask what the learner has read, changed and made, and under which conditions. A completed game may involve supplied assets, teacher-written sections or substantial collaboration. Those contributions can be valuable when their roles are clear.

Use a short example related to the receiving unit. Ask for a prediction, a trace or a change to one condition. This can reveal sequence, state and decision-making without requiring the learner to recreate a large project.

Include an accessible explanation. A learner may understand the algorithm but not the new classroom’s word for a loop or variable. Another may recognise the labels while needing the underlying relationship taught.

Record resources and assistance. Reading a teacher-provided program shows a different capability from designing one independently. Both can form part of a useful starting picture.

Avoid assigning a general ability level from interface confidence. A student who finds buttons quickly may still guess how the program behaves. A student new to the software may reason carefully through every step. The transition plan should connect the actual conceptual and practical evidence with the next lesson’s demands.

Contents · Previous chapter · Next chapter

An algorithm describes steps for a defined task. A program expresses a solution in a particular executable form, with conventions that must be learned. Keep the intended process distinguishable from the symbols used to represent it.

For the counting exercise, a plain-language algorithm can begin with a count of zero, examine each supplied number, add one when the number is greater than ten and report the final count. The student should explain why each part belongs.

When comparing block-based and text-based versions, identify the corresponding decisions and updates. Do not match pieces only by visual position. A block arrangement and a line of text can express similar logic while requiring different practical conventions.

Use the actual course language for precise implementation. Assignment, comparison, repetition and output can be written differently across languages. Learn those rules from the receiving course’s materials.

Check the shared behaviour with the same supplied input. If the outputs differ, inspect the algorithm and the implementation separately. This gives the learner a method for transition: preserve the task meaning, learn the new representation and test whether the represented steps still produce the intended result.

Contents · Previous chapter · Next chapter

Read the program in its actual execution order under the language’s rules. A visual layout can look like a story while the program follows a more specific sequence, event or repetition structure. Ask what happens next and why.

Use a short trace record. For each relevant step, note the input item, condition result and current state. The purpose is to make a changing value visible rather than guess the final answer from the project title.

For the supplied list 9, 10, 12 and a count starting at zero, the first comparison does not change the count. The second also leaves it unchanged. The third increases it to one under the strict greater-than-ten rule.

Ask where the final output happens. Reporting during each repetition would produce a sequence of intermediate counts rather than only the final result. Depending on the task, that could be useful or incorrect.

Use a changed order or different values after the first trace. A learner who understands the process can explain why rearranging these same values leaves this final count unchanged. That reasoning is stronger evidence than remembering that the original example ends at one.

Contents · Previous chapter · Next chapter

A variable holds a value used by the program under the language’s rules. In the counting example, the count records how many qualifying values have been encountered so far. Its meaning should remain connected with the task.

Begin at a defined initial value. Starting at zero fits a count before any values have been examined. Starting at one would create a different result unless the task or algorithm supplied a reason for that initial state.

Ask the learner to explain an update. Adding one to the count means one additional supplied value met the condition. It does not mean adding the value of that item to the total. Counting qualifying items and summing their values are different tasks.

Keep names and meanings clear. A descriptive label can help, while the program’s actual behaviour comes from the operations rather than the name alone. A variable called total can still be used incorrectly.

Use a fresh example to test the distinction. For values 11 and 12, the count above ten is two, while the sum of those qualifying values is twenty-three. The learner should be able to explain which result the requirement requests and how the update would differ.

Contents · Previous chapter · Next chapter

A condition determines which path or action applies under the program’s rules. Read the relationship carefully and test values that reveal its boundary. Ordinary language and programming notation need to preserve the same meaning.

For the strict greater-than-ten task, 9 does not qualify, 10 does not qualify and 12 does. A condition meaning greater than or equal to ten would count both 10 and 12 in the same supplied list.

Ask the learner to identify a value that separates two possible interpretations. Ten is more informative here than a value far above the threshold because it exposes whether equality is included.

Keep comparisons distinct from assignments in the course’s actual notation. The exact symbols differ by language, so use the receiving teacher’s materials for implementation. The concept remains a question about whether a relationship is true for the current value.

Avoid testing only cases expected to succeed. A program can appear correct when every supplied item lies above the boundary. Include a suitable range of cases so the condition’s meaning is inspected. The learner should be able to justify the expected result before running the test.

Contents · Previous chapter · Next chapter

A repetition structure carries out steps according to a defined rule. Identify what repeats, what changes between repetitions and what determines completion. The learner should know which part of the task the structure represents.

For the list exercise, the program examines each supplied value and applies the condition. The count can change while the same decision process is used. Finishing the list then leads to the final reported result.

Ask where state is initialised. Setting the count to zero before the repetition preserves earlier qualifying items. Resetting it during every repetition would erase part of the accumulated result.

Trace a small example that exposes the difference. With two qualifying values, an incorrectly reset count may still finish at one. A single qualifying value would not reveal that particular problem as clearly.

Use the actual language’s repetition conventions and teacher-provided environment. Different structures suit different tasks, and the course may introduce them in a particular sequence. The transition bridge should connect the new structure with its purpose, rather than require the student to memorise a visual shape or keyword without explaining how it processes the supplied items.

Contents · Previous chapter · Next chapter

Ask what kind of value the program is using and what the operation means for that kind of value. A number and a piece of text containing digits can look similar on screen while being treated differently by a language.

Use the receiving course’s examples to learn the actual rules. Do not assume that every language or tool converts input automatically in the same way. A transition task may need explicit teaching in the relevant data representation.

Keep the input specification clear. Does the counting exercise receive valid numerical values, or must the program also handle missing or unsuitable entries? Those are different requirements and should not be silently merged.

For a first conceptual exercise, supplied valid numbers let the learner focus on counting and conditions. A later unit may introduce validation or other input handling. Label which question the program is intended to solve.

Ask for an explanation that connects representation and behaviour. The learner should be able to identify whether an unexpected result arose from the algorithm, the input’s meaning or the implementation rule. That distinction helps prevent random edits when a program behaves differently in a new environment.

Contents · Previous chapter · Next chapter

Choose an input and write the expected output from the requirement. Then run or inspect the program under the course’s permitted arrangements and compare the result. The prediction gives the learner something precise to check.

Use a short explanation with the prediction. For 9, 10 and 12, the expected count is one because only 12 is strictly greater than ten. The reasoning matters more than a lucky guess.

If the result differs, preserve both records. Ask which step could explain the difference. A disagreement between prediction and output is information about the program or the learner’s understanding, not a reason to discard the attempt without inspection.

If the result matches, use another case chosen for a purpose. Agreement on one example does not establish correctness for every allowed input. A boundary value or empty supplied list may reveal a different part of the logic.

The Raspberry Pi Foundation source linked above provides a broader connection to reading and exploring programs. The exercise here is original: use a defined behaviour, make a reasoned prediction and inspect the actual result. That method can support transition across programming representations without depending on one product’s interface.

Contents · Previous chapter · Next chapter

Begin with the intended behaviour, the actual result and the smallest relevant case you can inspect. Propose a reason for the mismatch and choose a test or trace that can distinguish it from another explanation.

Suppose the counting program reports two for 9, 10 and 12. A plausible explanation is that equality has been included. Inspect the condition and test the boundary value ten. The reasoning should connect the observed result with the proposed cause.

Change one relevant feature where practical, then repeat the meaningful tests. Randomly rewriting several parts can produce a working result without teaching which change mattered. It can also introduce a new error that the original example does not expose.

Keep a brief record of the problem, test and correction. A sentence explaining the boundary error can be more useful for learning than a long screenshot collection with no account of the reasoning.

Ask the learner to explain why the correction fits the requirement. A teacher or peer can help locate a problem, while a changed task checks whether the learner now understands the relationship. Debugging becomes a learning method when it makes the decision process visible.

Contents · Previous chapter · Next chapter

A test set should be chosen for the task rather than merely repeated from the demonstration. Include cases that inspect the ordinary behaviour and the relevant boundaries or combinations within the stated input rules.

For the strict count-above-ten exercise, useful supplied examples include a value below ten, ten itself, values above ten and an empty list if empty input is allowed. Repeated qualifying values can inspect whether the count accumulates correctly.

State the expected output before using each test. An empty list should give zero under this defined task; 11 and 12 should give two; a list containing only 10 should give zero. Explain each result.

Do not claim that a few passing tests prove every possible property. They provide evidence about the selected cases. A reasoned account of the algorithm and its limits remains important.

Keep the testing appropriate to the course level. The learner does not need a complicated technical framework to compare input, expected result and actual result for a small exercise. A readable table can reveal whether the program solves the intended task and which case still needs investigation.

Contents · Previous chapter · Next chapter

Learn the receiving school’s method for saving, naming and submitting work. A student can understand a program while losing access to the current version or submitting a different file. This practical routine deserves its own teaching.

Keep source work, supplied assets and exported results distinguishable where the task uses them. An image of a program does not necessarily provide the editable project, and an exported result may not show the underlying decisions.

Use clear version information proportionate to the project. The teacher should be able to identify which version was tested and what changed after feedback. Follow the school platform’s actual process rather than assuming a file name alone proves submission.

Check that permitted resources are included through the required route. A project that relies on a local asset may behave differently when the receiving teacher opens it. The course can explain the appropriate packaging and access arrangements.

For the wider organisation connection, read homework after a school move. The aim is a practical routine through which the learner can locate, explain and share the actual work without confusing its representation with a different output.

Contents · Previous chapter · Next chapter

Find out whether the task permits pair discussion, shared development or independent production. These conditions can differ between learning activities and assessments. Use the actual assignment rather than assuming every coding project follows the same rules.

Label supplied sections and substantial help when required. A student may make an important change to teacher-provided code without having written the entire program. The contribution should remain visible and accurately described.

For paired work, give each learner an opportunity to explain decisions. One person operating the interface does not automatically show that both understand the logic. A role exchange or independent trace can provide more useful evidence.

If a tool suggests code, inspect its behaviour against the requirement and course rules. A correct-looking result may use ideas the learner cannot yet explain or solve a different question. The learner needs a truthful account of assistance and their own understanding.

The international group project guide develops contribution records for larger tasks. In coding, a small explanation of who supplied, changed and tested each relevant part can preserve both collaboration and an interpretable picture of individual learning.

Contents · Previous chapter · Next chapter

Use names, structure and explanations that help a reader follow the intended behaviour at the learner’s level. A small program should not become obscure merely to look advanced. Follow the conventions taught by the receiving course.

Explain important decisions and conditions. A note that the comparison excludes ten clarifies the requirement. A note repeating every obvious action without explaining its purpose may add little value.

Keep documentation consistent with the tested version. If the program changes from counting to summing, an old explanation can mislead the reader even when the code runs. Update the account of what the program does.

Ask another learner to predict the result from the program and its explanation. Their response can reveal unclear names, a missing condition or a mismatch between the stated intention and actual behaviour.

For the language bridge, let the student first explain the logic through an accessible representation, then build the course-language description. The aim is a readable evidence trail: a future reader can identify the task, understand the decision process and see how the tests relate to the claim that the program meets the requirement.

Contents · Previous chapter · Next chapter

Choose a project that gives the taught concepts a reason to work together. Define who uses the result and what the result needs to do. Keep the scope small enough for the learner to design, inspect and explain.

A fictional classroom organiser might count supplied values meeting a stated rule. The design should preserve the input conditions and output meaning. Additional decoration can be optional rather than displacing the core requirement.

Write a few success criteria in terms of behaviour. For example, the program uses the strict threshold, counts every supplied item once and reports the final count. These criteria support testing and feedback.

Discuss what the project will leave for a later unit. Handling every possible input format, building a complex interface or connecting external services may be outside the current learning purpose. A clear scope allows the learner to complete a meaningful piece of work.

Use the project to connect concepts rather than merely collect features. The learner should explain how the variable, repetition and condition cooperate. A compact program understood thoroughly can provide a stronger transition sample than a large assembly whose parts remain unexplained.

Contents · Previous chapter · Next chapter

Read the teacher’s comment beside the task and program. Identify whether the problem concerns the algorithm, notation, input assumptions, testing or explanation. Each calls for a different teaching response.

A message that the program counts the wrong cases may need a boundary comparison. A comment about insufficient evidence may need better-chosen tests. An unclear explanation may require language support even when the logic is sound.

Ask the learner to explain the feedback and propose a next action. If the comment is unfamiliar, use a concrete example or ask the teacher about the relevant part. Avoid treating every coding difficulty as a need to rewrite the entire project.

Use grades and assessment across countries for the broader interpretation. A mark needs the task, criteria and support conditions to become useful educational information.

Review the change through a fresh example. A corrected program can show response to help, while an independently explained modification provides additional evidence. The next lesson should build on what became usable and address the specific relationship that still needs teaching.

Contents · Previous chapter · Next chapter

Use this original plain-language task: count the supplied numerical values that are strictly greater than ten. Start a count at zero. For each value, add one to the count only if that value is greater than ten. After all supplied values have been examined, report the count.

Trace 9, 10 and 12. The count remains zero for 9, remains zero for 10 and becomes one for 12. The final expected result is one.

Now inspect a faulty interpretation that includes values equal to ten. It would report two for the same list. Testing the single value ten distinguishes the interpretations: the required output is zero, while the faulty equality-inclusive rule would give one.

Check accumulation with 11 and 12. The required output is two. If the count is incorrectly reset during each repetition, this case can reveal a different problem from the boundary mistake.

The answer check includes the rule, trace, expected outputs and explanation of each correction. Implement the exercise only through the language and environment taught by the course. The conceptual lesson is preserving a precise requirement through a changing state and a set of meaningful tests.

Contents · Previous chapter · Next chapter

Select a small program or permitted representation with its requirement, contribution statement and test record. Include the language or environment used, the support provided and what the learner can explain independently.

Add one development example if useful. An earlier boundary mistake and the reasoning that corrected it can show a learning process. A later changed task can demonstrate whether the concept transferred beyond that correction.

Keep a screenshot, editable project and exported output distinguishable. Ask the receiving teacher which materials they can use and how to share them through the approved route. The appropriate format depends on the actual course and tools.

Identify the next learning question. A student may understand conditions and repetition but need the new language’s syntax. Another may navigate the environment while still guessing how state changes. Those are different starting points.

Use the portable portfolio guide for the wider handover. The selection should help the next teacher plan a focused bridge, rather than present a collection of impressive project names as proof of competence across every part of computing.

Contents · Previous chapter · Next chapter

Must a learner restart when changing programming languages? Check the concepts and representations already understood. Some reasoning can transfer, while new notation and practical routines need explicit teaching.

Does a running program show it is correct? It shows a particular execution occurred. Compare behaviour with the requirement and use meaningful tests. A program can run while solving the wrong question.

Is debugging a sign of failure? Inspecting a mismatch can teach how the program works. The useful question is whether the learner can form, test and explain a reason for the problem.

Can supplied or generated code be included? Follow the task’s rules and label assistance accurately. The learner’s contribution and ability to explain the relevant behaviour remain important.

How can progress be recognised? Use a changed input, requirement or representation and record the support. A learner who can explain why a modification works shows more than someone who remembers which block or line was changed in a familiar example.

Contents · Previous chapter · Next chapter

Keep the basic questions available: what should this do, what state changes, which decisions apply and how can I check the result? Add the conventions and concepts of each new unit through the receiving course.

Do not assume every computing topic is the same as introductory coding. Data, systems, networks and other areas bring different questions and evidence. The habit of making relationships explicit remains useful while the subject knowledge expands. Explore how mathematics supports technology and computing for the broader subject connection.

Connect coding with a suitable wider task when it serves learning. A data comparison or simple representation can give a program a purpose, provided the learner understands both the program’s behaviour and the meaning of the material it processes.

Continue with school geography and evidence for a representation connection and the international education collection for the broader pathway.

The transition succeeds when the learner can explain a program, test a relevant case and ask a precise question about what remains unfamiliar. Those capabilities can travel between classrooms and languages while giving the next teacher a clear, evidence-based place to begin.

Contents · Previous chapter · Learning hub