Student coding and debugging literacy means being able to describe a computational problem, design a simple sequence or algorithm, trace its actual behaviour, test meaningful cases and repair errors without losing understanding. Writing code is not the same as clicking blocks until a sprite moves. A program can run successfully and still implement the wrong rule.
Ministry of Education V3.0 Reference 169 offers a Singapore student-facing guide to flowcharts, sequencing, selection, iteration, variables, testing, debugging, algorithmic thinking and ethical classroom computing. It includes a twelve-stage problem-to-tested-program protocol, original threshold and loop worked examples, a fault-classification table, a safe classroom paper simulation, parent questions, FAQs and eduKate Depth–Load–Transfer checks.
This independent eduKateSG article is not official MOE or SEAB Computing marking guidance, an application security review or permission to access networks or school-managed systems. Actual G1, G2 and G3 subjects, applications, language expectations and school availability vary. The examples here are invented, use fictitious data and do not control real student accounts or results.
1. Start With the Problem, Not the App Icon
Imagine a beginner wants a program that shows ‘Ready’ when a practice score is at least ten and ‘Keep practising’ otherwise. The learner can create a colourful screen in Scratch or a Python script, but the essential capability is specifying the rule correctly: scores of nine and ten have different outputs.
A computational solution begins with input, conditions and expected output. The student should be able to explain the rule in ordinary language before writing code or dragging blocks. Testing must include the threshold itself, which is where a common logic error appears.
2. The Current Singapore Computing Pathway
MOE’s 2026 G1 Computing Syllabus describes visual programming, algorithms, flowcharts, problem solving and game making, alongside document and media software and responsible computing. SEAB’s 2027 G1 SEC directory lists Computing K127 with Scratch and selected Microsoft Office software in its published context.
SEAB’s 2027 G2 directory lists Computing K237 with Scratch and applicable Office tools. The G3 directory lists Computing K349 and the relevant published software environment including Python, JupyterLab Desktop and Excel. Check current syllabuses and school offerings; these distinctions do not imply that every school provides every combination.
School assignments may use visual blocks to introduce the same logic that later appears in textual languages. The purpose is transferable reasoning, not a hierarchy in which one child’s beginner language is treated with contempt.
3. An Algorithm Is a Set of Defined Steps
An algorithm describes a procedure for transforming input into an output. It can be written in plain language, pseudocode or a suitable flowchart before being implemented. A diagram with arrows is useful when it reveals the actual sequence and branch logic, but decoration alone does not make it correct.
| Algorithm component | Meaning | Example |
|---|---|---|
| Input | Value supplied to the process | A fictional practice score |
| Variable | Named item of state | score |
| Comparison | A test that may be true or false | score ≥ 10 |
| Branch | Different action for different outcomes | Ready versus Keep practising |
| Loop | Repeat an operation appropriately | Add values from a list |
| Output | Result presented to the user | Displayed feedback message |
4. Eight Rooms in a Program-to-Evidence Route
| Room | Question | Typical failure |
|---|---|---|
| Purpose | What exactly must the system do? | Building a decorative app with no stated rule |
| Input | What values and types are expected? | String and number confused |
| Logic | Which decision or repetition is valid? | At least treated as strictly greater |
| Trace | What does each step actually do? | Guess from desired outcome |
| Test | Which normal and boundary cases matter? | Only one easy input tested |
| Fault | What kind of error occurred? | Running treated as equivalent to correctness |
| Safety | Whose data and accounts may be used? | Private class information used in a demo |
| Transfer | Can the learner explain and fix a new program? | Copied working code mistaken for mastery |
5. Twelve-Stage Algorithm and Debugging Protocol
Stage 1 — Define the input, output and purpose
A program needs a bounded task: sort three numbers, show a message after a score threshold or count selected items. State what enters the process and what result should appear. A colourful app without an explicit user need is not necessarily a good computing solution.
Stage 2 — Read the actual subject and assignment requirements
School Computing and coding clubs can use Scratch, flowcharts, Python, spreadsheets or other approved tools. MOE and SEAB curricula vary between G1, G2 and G3, and schools may not offer every subject. Use the teacher’s actual tool permissions and task criteria before choosing a language.
Stage 3 — Plan a small sequence on paper first
Translate the problem into understandable steps before adding animation or interface decoration. A flowchart can show an input, process, decision and output. Define variables and expected meanings so the programmer can detect missing steps later.
Stage 4 — Separate condition from consequence
An if/else branch checks a Boolean condition and runs the corresponding action. If the task says score at least ten, the threshold includes ten; a greater-than test excludes it. Wording such as at least, more than, below and no more than matters.
Stage 5 — Trace a simple case by hand
Use a small ordinary input and follow the program’s steps in order, recording how variables change. The child should know why the selected output follows from the code. Guessing the result from the intended story rather than actual operations can hide bugs.
Stage 6 — Include boundary cases deliberately
Test one value below, exactly at and one above a threshold. A loop can be checked with zero, one and several items when those inputs are legitimate. Boundary cases reveal errors that an easy example may not expose.
Stage 7 — Identify errors without blaming the programmer
Syntax errors prevent the program being read correctly, runtime errors arise during execution, and logic errors produce unexpected results despite running. Distinguish the observed failure from its cause before changing code. A red error message is a clue, not a moral judgement.
Stage 8 — Change the smallest relevant part and retest
Fix one expression, condition, variable or sequence at a time. Run the earlier cases again to check that a correction did not break something else. Keep an authorised working version and note what changed so a beginner can retrace the repair.
Stage 9 — Use loops and counters with precise start values
A total accumulator generally starts at zero if it represents a sum of no items, while an appropriate counter may start at zero or one according to the task. An extra increment or the wrong starting value can create an off-by-one result; understand the invariant rather than memorise a patch.
Stage 10 — Protect privacy, security and permitted access
Do not use classmates’ private accounts, scrape school portals, share passwords, build a prank that harms others or circumvent device controls. Fictional test values are usually sufficient to demonstrate branching, iteration and calculation without collecting sensitive student data.
Stage 11 — Validate the output against real task requirements
A script that runs without crashing may still be wrong if it misinterprets an input, ignores a unit or gives the correct result only on one example. Compare output with independent calculations and the user’s actual goal. Do not call generated AI code verified simply because it looks plausible.
Stage 12 — Explain and transfer the algorithm independently
The pupil should describe what each step does, predict a new output, name a possible failure and repair a similar code fragment without copying an entire solution. A useful end state is explain–trace–test–fix capability, not merely pressing the green flag.
6. Worked Example A: The Difference Between ≥ and >
A fictional teacher sets the threshold rule: if a score is at least 10, display ‘Ready’; otherwise display ‘Keep practising’. The correct comparison is score ≥ 10, not score > 10. This is a classroom practice program, not a real school eligibility or promotion rule.
| Test input | Correct condition score ≥ 10 | Expected output |
|---|---|---|
| 9 | False | Keep practising |
| 10 | True | Ready |
| 11 | True | Ready |
| 0 | False | Keep practising |
| −1 | False under arithmetic condition | Keep practising; real task may need input validation |
A wrong code statement using score > 10 would give ‘Keep practising’ for score 10, even though the rule explicitly includes that value. The program might run without an error message, so this is a logic bug revealed by testing the boundary.
7. The Algorithm in Readable Pseudocode
The following is invented pseudocode designed to teach branching, not a prescription for a particular compiler or official examination notation.
READ score
IF score >= 10 THEN
DISPLAY "Ready"
ELSE
DISPLAY "Keep practising"
END IF
The important symbol is the inclusive comparison. Students can convert the logic to permitted Scratch blocks or another actual school language when instructed. Because input types vary between tools, the learner may also need to check that the provided value is a number, not text or missing data.
8. A Simple Flowchart With Four Useful Shapes
| Shape in common classroom notation | Purpose | Fictional example |
|---|---|---|
| Start/end terminal | Mark beginning and termination | Start; End |
| Input/output shape | Receive or display information | Read score; Display message |
| Process rectangle | Carry out operation or assignment | Set total = 0 |
| Decision diamond | Ask a yes/no question | Is score ≥ 10? |
| Arrow | Show logical direction | True branch and false branch |
Flowchart symbol conventions can differ across textbooks. The actual teacher’s syllabus and notation rules govern assessed drawings. More important than the precise appearance is that every possible valid input follows a defined route and the output corresponds to the rule.
9. Worked Example B: A Loop That Totals Three Values
Imagine a fictional learner records practice scores of 3, 4 and 5. To calculate their sum, initialise total to zero and add each score once. The successive totals are 3, 7 and 12. A loop or a sequence of three additions can implement this in different languages.
| Loop stage | Added value | New total |
|---|---|---|
| Initial value | None | 0 |
| First item | 3 | 0 + 3 = 3 |
| Second item | 4 | 3 + 4 = 7 |
| Third item | 5 | 7 + 5 = 12 |
| Result | 3 + 4 + 5 | 12 |
If the programmer accidentally sets total = 1 initially, the output becomes 13. The instructions might be syntactically valid and execute without crashing, but they do not calculate the requested sum. Testing with small values helps reveal the bug.
10. Worked Example C: The Off-by-One Counter
A class wants to repeat a harmless simulated action exactly four times. If a loop starts its counter at zero, tests whether the counter is less than four and increments by one each time, the valid counter values before the action are 0, 1, 2 and 3. That is four iterations.
| Iteration | Counter before action | Number of actions completed after |
|---|---|---|
| 1 | 0 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 3 |
| 4 | 3 | 4 |
| Next check | 4 | Loop stops for condition counter < 4 |
Changing the condition to counter ≤ 4 without changing the starting and increment conventions would run five times. This is a boundary or off-by-one bug. To prevent it, trace the first and last iteration, then compare the total number of actual actions with the task.
11. Syntax, Runtime and Logic Errors
| Error category | What happens | Illustrative response |
|---|---|---|
| Syntax | The language or tool cannot interpret the written instruction | Correct the malformed statement following the actual language rules |
| Runtime | An action fails during execution | Inspect the actual input, resources and conditions |
| Logic | The program runs but gives the wrong output | Trace relevant cases and check the rule |
| Data or type mismatch | Input is a string when a number was expected | Validate or convert the input appropriately |
| Permission or access issue | Program cannot use an authorised file or resource | Ask school staff; do not bypass controls |
An error is a clue to the mechanism. Rewriting the entire program without knowing which part failed can introduce additional mistakes. A good beginner changes one relevant condition and tests the original cases again.
12. Keep Debugging Evidence Small and Honest
A short debugging log can contain the input, expected output, observed output, suspected cause, single change and retest result. This helps the learner see whether the repair worked. A project does not need hundreds of screenshots showing every failed attempt.
| Field | Invented threshold program example |
|---|---|
| Test input | 10 |
| Expected | Ready |
| Observed with wrong > comparison | Keep practising |
| Diagnosis | Boundary test excludes exactly 10 |
| Correction | Use ≥ instead of > |
| Retest | 9 → Keep practising; 10 → Ready; 11 → Ready |
13. Why Code Can Run Yet Be Unsafe or Unfair
A learner should not test programs by accessing other children’s marks, school accounts or private records. A class project can use fictional scores. A correctly written script that leaks private information or violates consent remains unacceptable even if its arithmetic works.
- Use teacher-approved software and fictitious data for ordinary learning.
- Do not access accounts, passwords or restricted school systems without authority.
- Do not build or share programs designed to harass classmates or obtain private information.
- Verify any AI-generated code before running it in an approved environment.
- Check input assumptions, outputs and side effects.
- Ask trained adults for help with school device and security settings.
- Use a suitable paper trace when a learner does not have the required software.
14. Responsible AI Use in Beginner Computing
An AI assistant may suggest a code block or explain a syntax error, but it can also produce bugs, incorrect logic or an unsafe external dependency. School rules determine whether AI support is permitted for a task. Students should understand and test each suggested operation before accepting it.
A pupil who pastes a complete script that works on only one demo input may not have mastered loops or conditions. A safer learning approach is to ask ‘why does this value take the wrong branch?’ and verify the fix with normal, boundary and unusual inputs.
15. A Classroom Algorithm Trace Exercise
A teacher gives pupils four fictional Scratch-like blocks on paper: set total to zero, repeat through [3, 4, 5], add each number and display total. A second example contains the deliberate initial-value bug. Students trace both without needing to open an external platform.
| Challenge | Student output | Concept |
|---|---|---|
| Trace correct sequence | Total 12 | Iteration and accumulation |
| Find one wrong starting value | Total 13 if total begins at 1 | Initialization |
| Test inclusive threshold | Input 10 produces Ready | Boundary logic |
| Identify incorrect comparison | score > 10 fails at 10 | Logic debugging |
| Describe permitted data | Invented scores only | Privacy and safe learning |
16. Depth, Load and Transfer: The eduKate Education OS
eduKate’s independent model checks Depth (why the algorithm produces a particular result), Load (accurately following several steps under suitable demands) and Transfer (repairing a similar but unfamiliar program). It is not an official SEC Computing rubric.
| Dimension | Learner evidence | Repair |
|---|---|---|
| Depth | Explains why at least ten requires an inclusive boundary | Compare two true/false conditions |
| Load | Traces a small loop and accumulator reliably | Practise state tables with varied inputs |
| Transfer | Finds an off-by-one bug in an unfamiliar counting example | Test first, last and boundary values |
17. Questions for Parents and Tutors
- What is the input and expected output?
- Can the child explain the algorithm before touching a computer?
- Which steps repeat and when do they stop?
- Does ‘at least’ include equality?
- What happens one below, exactly at and one above a threshold?
- Does the code run but give a wrong answer?
- Which single change fixes the observed problem?
- Has the pupil tested the change independently?
- Does the project avoid private accounts and unauthorised data?
18. Frequently Asked Questions
Is Scratch less educational than text-based programming?
No. Visual programming can teach sequencing, selection, iteration and testing. The appropriate tool depends on learner readiness, school curriculum and task.
Does the 2027 SEC Computing subject use the same software at all G levels?
No. SEAB’s published G1, G2 and G3 subject directories identify different arrangements and software environments. Check the actual school and year.
Does a program that runs without crashing prove it is correct?
No. Logic errors can produce wrong outputs. Test expected and boundary cases, and compare with the task.
Why test the threshold itself?
Because inclusive and exclusive comparisons differ exactly at equality. A score of 10 distinguishes > 10 from ≥ 10.
Do children need to write unsafe real-world software to learn debugging?
No. Fictitious input values, paper traces and approved classroom examples are sufficient to teach these foundations.
Can AI automatically fix every bug?
No. Generated suggestions need verification. A pupil must still understand the intended behaviour and check outputs.
19. Closing Principle
Define the task. Trace the steps. Test the boundary. Find the real fault. Repair one cause. Check again. Computing literacy is the power to explain and control a process, not merely celebrate a program that opens.
Related eduKateSG References and Official Sources
- MOE V3.0 Reference Library
- Reference 12 — Digital Learning and AI Approval
- Reference 28 — Privacy and Consent
- Reference 35 — Independent Assessment
- Reference 45 — Algorithms and Attention
- Reference 79 — Robotics and Human Oversight
- Reference 104 — Debugging as Error Repair
- Reference 118 — Project-Based Learning
- Reference 123 — Device Access
- Reference 149 — Self Study
- Reference 150 — Team Learning
- Immutable Clementi Teaching Reference
- MOE — 2026 G1 Computing Syllabus
- SEAB — 2027 SEC G1 Computing
- SEAB — 2027 SEC G2 Computing
- SEAB — 2027 SEC G3 Computing
- SEAB — SEC Syllabus Directory