At a glance
Solo or pairs · six working periods · remixes demoed in a short class showcase during the final period · one changed program plus a before-and-after write-up that is yours alone
What you are making
Most professional programming is not writing new code — it is reading code someone else wrote and changing it, which is why Debugging Is the Job is a discussion and not a complaint. This task makes that real work official: start from any program in the Programs folder and make it do something meaningfully new.
Most people start from The Text Adventure because it begs to be
extended, but Guess My Number, Mad Libs, The Dice Roller,
The Password Checker, and The Chatbot are all fair game.
“Meaningfully new” means new behaviour — a rule, a feature, an external
module or library incorporated (such as using random, math, or time
as taught in Subprograms and Modules), or adapting the artifact to
support diverse users and contexts. New strings and renamed variables are
a coat of paint, not a remix. You also practice sound file management by
keeping backup copies of the original starter code in your project directory
(Files and the Cloud).
You hand in the remixed program and a before-and-after write-up: what the original did, what yours does, what you changed, and why.
If you work in a pair the program is shared, but the write-up is yours alone — written separately, in your own words, naming which changes were yours and which were your partner’s. That write-up, and what you say at the showcase, are what your own mark is built from; there is no shared mark on this task. Two periods set time aside for writing it — a slot mid-build and a longer one at the end — so nobody ends up copying a partner’s paragraphs at eleven at night. For a pair, the three rows below that describe the program — meaningfully new, still readable, an honest demo — are read against the changes your write-up claims as yours, not against the file as a whole.
How to work
- Choose your base program and read it completely before touching it. Predict what each part does, Predict the Output-style, then run it and check. Annotate the parts that surprised you.
- Plan the new behaviour in one sentence, and check the sentence with me — this is where “new coat of paint” gets caught early.
- Change one small thing, run it, repeat — big-bang edits produce big-bang errors. When something breaks, and it will, Debugging Step by Step is the way through.
- Write the before-and-after as you go, including what broke on the way; the detours are the most interesting part of the story.
- Demo at the showcase: original behaviour first, then yours. Most of the remixing happens in the working periods, where a stall is something I can walk over to — How Marks Work explains why what I watch counts.
Success criteria
| Quality | What it looks like in your remix |
|---|---|
| The original understood | Your write-up explains what the base program did |
| Meaningfully new | The remix does something the original could not do |
| Modular and library extensions | Modularity, custom subprograms, or external modules extend functionality |
| Change with a reason | The write-up says why this change, not just what |
| Errors worked through | One error and its resolution appear in the story |
| Still readable | A stranger could find your changes and follow them |
| An honest demo | The showcase shows before and after, bugs included |
| Your own part named | The write-up says which changes were yours and which were your partner’s |
Reflect
Write a Dev Journal entry: what did reading someone else’s code teach you that writing your own had not? Name one choice the original author made that you would have made differently — and one you plan to steal for your own programs from now on.
If remixing feels like cheating (click to expand)
It is the opposite — it is the profession. Every programmer you have heard of spends most days inside other people’s code, and remixing a working program teaches you how programs are organised, which no amount of starting from blank files can. Read boldly; change bravely.
Curriculum connection
A1.3
develop computational artifacts for a variety of contexts and purposes that support the needs of diverse users and audiences
Link to original
B2.1
use file management techniques, including those related to local and cloud storage, to organize, edit, and share files
Link to original
C2.6
interpret program errors and implement strategies to resolve them
Link to original
C3.1
analyze existing code to understand the components and outcomes of the code
Link to original
C3.2
modify an existing program, or components of a program, to enable it to complete a different task
Link to original
C3.4
write programs that make use of external or add-on modules or libraries
Link to original