Year 9 Digital TechnologiesUnits 1 and 2

 

🎮
Writing Good Code - An Introduction
Year 9 Digital Technologies • Think first, code second • Learn the brain-tools coders use
🧠 Computational Thinking
Quick Nav
Tip: Click any card title to expand/collapse. Most activities include a folded Possible solution.
🎯 What is coding (and what isn’t it)? ›
Coding is writing instructions that a computer can follow exactly. Computers don’t “guess what you meant” — they do what you wrote.
So what do coders actually do?
  • Plan the solution (what should happen?)
  • Write the instructions (code)
  • Test it (does it work?)
  • Debug it (why is it broken?)
  • Improve it (make it clearer/faster/easier to use)
Coding is NOT
  • “just typing fast”
  • “memorising everything”
  • “being a maths genius”
Coding IS
  • clear thinking
  • trial + error (normal!)
  • patterns and reusable ideas
Activity: “Robot-proof” instructions (2–3 minutes)
Write instructions for a robot to complete this task: “Open a browser and get to the Thonny download page.”
Your instructions must include:
  • What to click (and where)
  • What to type
  • What to do if a pop-up appears
  • What “success” looks like at the end
Possible solution (one example) ›
  1. Click the Start button.
  2. Type Chrome (or your browser name) and press Enter.
  3. Click the address bar at the top of the browser.
  4. Type thonny.org and press Enter.
  5. When the page loads, find the section that says Download.
  6. Click the Windows or macOS download link that matches your computer.
  7. Success looks like: the download starts OR you can see the correct download option on-screen.
Try this (solo or pairs): The “too vague” detector
Below are three instructions. For each one, rewrite it so it is robot-proof.
  • “Open the file.”
  • “Run the program.”
  • “Save your work.”
Hint: include where the file is, what it’s called, and what you expect to see afterwards.
🔁 IPO: Input → Process → Output ›
The IPO model is a simple way to describe what a program does: Input = what goes in, Process = what happens, Output = what comes out.
A super simple IPO example
INPUT: your name
PROCESS: add "Hello " to the front of it
OUTPUT: "Hello Prajwal" (or whatever name you typed)
IPO helps you plan BEFORE coding. If you can’t describe your Input/Process/Output, your code will be chaos.
Activity: IPO for a mini-game scoreboard (3–5 minutes)
You’re designing a scoreboard for a simple class tournament game (e.g., Rocket League, FIFA, Valorant, Mario Kart…). The scoreboard should:
  • store player/team names
  • add points when someone scores
  • show who is currently winning
Your task
Write IPO for the scoreboard. Make it specific:
  • What EXACT inputs exist? (button press? team selected? points?)
  • What EXACT process happens? (update totals, compare scores)
  • What EXACT output appears? (numbers on screen, “Team A winning!”)
Possible solution (one example) ›
INPUT:
- team1_name, team2_name
- "score" button press for Team 1 or Team 2
- points to add (usually 1)

PROCESS:
- add points to that team’s total
- compare totals to find the leader

OUTPUT:
- display Team 1 score + Team 2 score
- display "Team 1 leading" / "Team 2 leading" / "Tied"
Try this: IPO speed-run (choose ONE)
Pick ONE situation and write IPO. Keep it short but specific (3 lines is fine).
  • A “mystery loot box” opener (random reward)
  • A music “skip track” button
  • A school canteen queue number display
  • A “battery low” warning system
Minimum requirement: include at least 2 inputs, at least 2 processes, and at least 2 outputs.
🧩 Decomposition: break big into small ›
Decomposition means breaking a big problem into smaller parts that are easier to build and test. If you can’t decompose it, you can’t code it (yet).
How to decompose (a method that works)
  1. Describe the goal in one sentence.
  2. List the features a user would want.
  3. Turn features into tasks the computer must do.
  4. Group tasks into chunks (input, processing, output, storage).
Activity: Decompose a game “NPC shop” (5–7 minutes)
You’re building a simple shop in a game where a player can buy items (e.g., sword, potion, shield). The player has coins. Each item has a cost.
Your task
Decompose the shop into at least 8 smaller parts. Use this structure:
  • Inputs: what the player does
  • Processing: what the shop checks/updates
  • Outputs: what the player sees/hears
  • Storage: what data must be remembered (coins, inventory)
Possible solution (one example) ›
  • Input: player opens shop
  • Output: display item list + prices
  • Input: player selects item
  • Process: check if player coins ≥ price
  • If yes: subtract coins
  • If yes: add item to inventory
  • If no: show “Not enough coins”
  • Output: update coins display
  • Storage: remember inventory + coins even after leaving shop
Try this: Decompose a “Daily Quest” system
Imagine your game gives you 3 daily quests (e.g., “Win 1 match”, “Collect 10 coins”, “Log in today”). Decompose it using these prompts:
  • How are quests created each day?
  • How does the game check progress?
  • How does it show progress to the player?
  • What reward happens when a quest completes?
  • What resets at midnight?
Minimum: write 10 bullet points total across input/process/output/storage.
🔎 Pattern recognition: spot repeats ›
Pattern recognition is noticing repeats (in steps, data, or code) so you can reuse a solution. Patterns are how you code faster AND with fewer bugs.
Common patterns Year 9 coders see a LOT
  • Repeating steps: “do this again and again” → loops
  • Checking rules: “if this happens…” → if/else
  • Lists of things: items, names, scores → arrays/lists
  • Same output format: templates → functions
Activity: Pattern hunt — “Combo Lock” mini-game (5 minutes)
Imagine a game lock that opens with a 4-symbol code (like 🔺🔻⬅️➡️). Players get 5 attempts. After each attempt, the game gives feedback:
  • Correct = right symbol in the right place
  • Close = symbol exists but in a different place
  • Wrong = symbol not in the code
Your task
Identify at least 4 patterns in how the lock works. For each pattern, write:
  • What repeats?
  • What could code reuse?
  • What variable would track it?
Possible solution (pattern examples) ›
  • Repeat: each attempt follows the same steps → loop over attempts
  • Repeat: compare 4 positions each time → loop over 4 symbols
  • Rule check: correct/close/wrong → if/elif/else decisions
  • Tracking: attempts left → variable that decreases
  • Template output: show feedback in same format each time → reusable function
Try this: Find patterns in your own habits
Pick ONE of these and list the repeating steps:
  • Getting ready for school
  • Joining an online game with friends
  • Making a snack
  • Charging your devices overnight
Then answer:
  • Which step could fail? (edge case)
  • Which steps repeat every time?
  • What would you “automate” first?
🧠 Abstraction: focus on what matters ›
Abstraction means keeping the important details and ignoring the rest — especially at the start. Great coders don’t build everything at once. They build the core first.
A simple way to do abstraction
  1. Write the core goal in one sentence.
  2. List the 3 must-haves (without these, it fails).
  3. List the nice-to-haves (cool but optional).
  4. Build must-haves first.
Activity: Abstraction — Design a “Game Settings” menu (5 minutes)
Imagine you’re making a settings menu for a simple game. Your menu might include things like volume, controls, subtitles, graphics, difficulty, etc.
Your task
Create two lists:
  • Must-haves (3) — required for the game to be playable
  • Nice-to-haves (5) — optional extras
Then explain (1–2 sentences): why you placed each must-have in that list.
Possible solution (one example) ›
Must-haves:
  • Volume control (so sound isn’t painful / can be muted)
  • Control remap (accessibility + preference)
  • Difficulty setting (so it’s playable for different skill levels)
Nice-to-haves:
  • Graphics presets
  • Colourblind mode
  • Subtitles style options
  • Vibration settings
  • Custom crosshair
Try this: “Build it in layers” challenge
You are making a timer tool for students. Write what you would build in:
  • Version 1 (minimum viable): what must it do?
  • Version 2 (better): what improves it?
  • Version 3 (deluxe): what’s a cool extra?
Hint: Version 1 should be so simple it could be coded quickly.
🪜 Algorithmic thinking: step-by-step instructions ›
An algorithm is a clear, ordered set of steps that solves a problem. Good algorithms include rules (IF/ELSE) and handle “weird inputs”.
A Year 9 algorithm checklist
  • Steps are in order
  • Each step is specific (robot-proof)
  • Includes at least one IF/ELSE decision
  • Includes at least one edge case (“what if…?”)
Activity: Write an algorithm for a “respawn timer” (5–7 minutes)
In a game, when a player is eliminated, they respawn after a delay. Design a respawn timer that:
  • counts down from 10 seconds
  • shows the number each second
  • respawns the player at 0
  • has a rule: if the player quits early, stop the timer
Your task
Write the algorithm in steps (numbered list). Include:
  • Inputs (what triggers respawn? what means “quit”?)
  • Processing steps (countdown logic)
  • Outputs (what the player sees)
Possible solution (one example) ›
  1. When player is eliminated, set time = 10.
  2. Display “Respawning in 10…”
  3. WHILE time > 0:
    • If player quits match, stop and exit the loop.
    • Wait 1 second.
    • time = time − 1
    • Display “Respawning in time…”
  5. If time == 0 and player is still in match, respawn player.
Try this: “Anti-rage-quit” rule
Add a rule to your respawn algorithm: If a player quits during the countdown, they lose 50 coins.
Write:
  • What variable tracks coins?
  • Where do you subtract coins in the algorithm?
  • What message should display?
🕸️ Systems thinking: the big picture + connections (Advanced) ›
Systems thinking is about understanding how parts connect and influence each other. In digital tech, “the system” includes users, devices, networks, data, rules, and feedback.
A simple systems map (text version)
PLAYER → GAME CLIENT → INTERNET → GAME SERVER → DATABASE
↑ ↓ ↓ ↓
settings updates lag/errors saved data
If one part breaks (e.g., internet), it can affect everything else (lag, disconnects, lost progress).
Activity: Systems thinking — “Matchmaking” (6–8 minutes)
Imagine a multiplayer game that tries to match players with similar skill. Your system needs to:
  • collect a player’s skill rating
  • find other players online
  • create teams
  • start a match
  • update ratings after the match
Your task
Draw the system as a list of parts and arrows (text is fine). Then answer:
  • What happens if the server is down?
  • What happens if the player’s internet is unstable?
  • What happens if the rating is wrong?
Possible solution (one example) ›
Parts + connections:
  • Player device → game client app
  • Game client → internet → matchmaking server
  • Server → database (player ratings, history)
  • Server → game server instance (actual match)
  • Match results → database → updated ratings → next matchmaking
Failure impacts:
  • Server down → no matchmaking, no matches start
  • Unstable internet → lag/disconnect → unfair match outcomes
  • Wrong rating → unfair teams → frustration → players quit → fewer players online (feedback loop)
Try this: Find the feedback loop
In matchmaking, a feedback loop might be: Unfair matches → players quit → fewer players online → matchmaking gets worse → more players quit.
Write ONE feedback loop for:
  • a school Wi-Fi system
  • a canteen ordering system
  • a classroom behaviour rewards system
🧪 Quick Practice Bank (10 scenarios - only pick any 1 at a time) ›
Choose any one scenario. For each one, complete: IPO → Decomposition → Patterns → Abstraction → Algorithm.

To keep it manageable: aim for 3–5 bullets per section.
1) “Loot Drop” simulator (random reward)
A player opens a chest and gets a random item (common/rare/legendary). Must show what they got and update inventory.
Stretch: add “pity timer” (after 10 commons, guarantee a rare).
2) Friend list status tracker
Shows which friends are online/offline/in-game. Updates every minute. Lets you search a name.
Stretch: show “last seen” time.
3) “Energy bar” stamina system
Sprinting drains stamina, resting regenerates it. If stamina hits 0, sprint is disabled until it recovers.
Stretch: different activities drain at different rates.
4) Classroom tournament bracket tool
Enter teams, generate matchups, record wins, move winners forward until a champion is declared.
Stretch: handle an odd number of teams (bye rounds).
5) “Daily login reward” system
If a player logs in each day, they get a reward. Missing a day resets the streak (or reduces it).
Stretch: reward improves with streak length.
6) “Boss fight” health tracker
Track boss HP. Different attacks deal different damage. When HP reaches 0, trigger victory message.
Stretch: phase changes at 70% and 30% HP.
7) “Queue number” system (real world)
Like at the DMV: generate a ticket number, call next, display “Now Serving”, track who is waiting.
Stretch: separate queues (priority vs normal).
8) “Music mood” playlist filter
Choose a mood (chill/hype/focus). Filter songs with tags and generate a playlist.
Stretch: avoid repeating the same artist twice in a row.
9) “Smart home lights” rules
Lights turn on based on time + motion sensor. They turn off after 2 minutes with no motion.
Stretch: “Do not disturb” mode after 10pm.
10) “School assignment tracker”
Add assignments with due dates, sort by due date, show overdue tasks, and mark completed tasks.
Stretch: send a warning 2 days before due date.
Inspired by
Coding Introduction (Digital Solutions 2025): https://damom73.github.io/digital-solutions-text-2025/intro/