teach-coding

name	teach-coding
description	Age/grade-appropriate approach for a coding/programming subject — read this BEFORE create-study-material or create-test when the topic is coding/programming, in addition to that skill.

Teaching coding

Coding is not like other subjects: the right material differs sharply by age, and — especially before high school — the goal is computational thinking (breaking a problem into steps, sequencing, loops, conditionals, spotting a logic error), not memorizing a language. A child who can confidently trace and debug simple logic has learned the valuable skill even if she's barely touched real syntax. Index on reasoning, not on covering language features.

Read memory/child-profile.json for grade, then match ONE band:

1. Grade ~KG–2 (ages ~5–7): no syntax on screen at all. This age needs hands-on, drag-and-drop tools (ScratchJr, code.org's earliest courses), which this app can't provide — tell the parent that plainly rather than faking it with text code a 6-year-old can't use. What you CAN build: a clickable unplugged logic page — move a character step by step to a treasure, or tap pictures into the right order — sequencing as a game, no code anywhere.

2. Grade ~3–8 (ages ~8–13) — the default for most requests. Logic first, made real through something she can click and watch work. A page she can only read is far less alive than one that responds, so prefer building a small, complete, already-working interactive demo that embodies the concept over a dry written exercise. Conditionals suit a branching choose-your-own-adventure; sequencing, a character that advances one step per click; loops, a counter or repeating animation she drives; variables, something that visibly changes and remembers a value across clicks.

   Alongside the demo, show the short simplified pseudocode that drives it (a styled read-only block, e.g. "if left button clicked → show the left path") so she connects this reasoning to that behaviour — the demo teaches the logic, it isn't a disconnected game. Then reinforce with the drier styles AFTER it, never instead of it: "predict the output", "find the bug" (one deliberate logic error), "trace it by hand". Introduce only a few constructs at a time.

3. Grade ~9–12 (ages ~14+): real code, real small projects. Syntax depth and independent building matter more here, but finishing something real still beats a syntax tour — favour small complete projects (a simple game, a script that solves an actual small task). The "build something that visibly works" instinct from band 2 still applies, just with more real syntax alongside it.

Interactivity follows skills/_shared/html-design.md as-is: build clicking and branching with plain <button>s (never a text input), and any button representing a genuine CHOICE must use SQ.choose so you actually see what she picked. Purely decorative motion — a counter ticking, a sprite moving — is fine as plain client-side JS, since nothing is being chosen. A demo can also live in a show_scene snippet rather than the activity's fixed file when you want it to follow a direction she takes the lesson in.

Out of scope: a live code EDITOR where she types and runs her own arbitrary code — this app has no code-execution engine, so never build or imply one. Every demo is pre-built by you and already working when she opens it.