coding missions: A Practical Course with Cassian North

Start with the purpose

Place coding missions inside a small but realistic software or digital-safety task. Name the result a learner is trying to produce and the constraints that make the skill useful.

How coding missions actually works

These are the load-bearing ideas. Everything later in the course is an application of one of them, so it is worth reading slowly and returning to when something stops making sense.

• Programs are state changing over time. Most confusion comes from not knowing what a variable holds at a given moment. Reading code as a sequence of state changes, rather than as instructions, is what makes unfamiliar programs understandable.
• Make it work, then make it clear. Working code that nobody can read becomes unmaintainable within weeks, including for its author. Naming and structure are not decoration; they are how future changes stay cheap.
• A bug is a disagreement between belief and behaviour. Debugging is the process of finding which of your beliefs about the program is false. Printing or inspecting values converts an argument with the computer into an observation.

Misconceptions worth clearing early

Each of these is common, understandable, and expensive to leave in place. Recognising them now saves rework later.

• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.
• Reading code without running it. Code looks like it does what it was named to do. Fix: Run it with a value you can predict by hand, then compare the real output with your prediction.
• Treating an error message as noise. Long stack traces look intimidating and unspecific. Fix: Read the first line and the file and line number; that pair usually names the actual problem.

Build the mental model

Connect the key terms as a process rather than a word list. Use this sequence: decompose the problem, build one testable step, inspect the result, and debug deliberately.

Catch the common miss

Compare a surface-level attempt with one that shows correct behavior, readable structure, useful tests, and an explained decision. Explain the single difference that matters most.

Watch the whole process

Trace a model from the initial prompt to a working program, configuration, or technical walkthrough. Mark each point where the learner must observe, choose, or verify rather than act automatically.

Worked example: Isolating a regression by bisecting history

Follow each step and predict the next before you read it. Predicting first is what turns a demonstration into practice.

1. Confirm the bug is present on the current commit and absent on a known-good release tag.
2. Start a bisect, marking the current commit bad and the old tag good.
3. The tool checks out the midpoint commit. Test it and record the verdict, then repeat.
4. A range of roughly 1000 commits narrows to a single culprit in about 10 iterations, leaving one small diff to read.

Converting a search into repeated halving turns an open-ended reading task into a small, fixed number of concrete tests.

Where this usually goes wrong

Watch for these while you work through the demonstration rather than afterwards.

• Changing several things at once. It feels faster, especially with a deadline in view. Fix: Change one variable per run. Otherwise a real fix and a newly introduced bug can cancel out and you learn nothing from the result.
• Trusting the reported line number blindly. The stack trace points precisely at where the failure surfaced. Fix: The cause is often much earlier, such as a bad value written far upstream. Trace the data backwards, not only the call stack.
• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.

Practice with scaffolding

Repeat the model with one detail changed. Keep the prompts visible and say or write the reason for each choice before continuing.

Check before feedback

Use correct behavior, readable structure, useful tests, and an explained decision as the quality test. Make one self-correction before asking the tutor to review the result.

Read the situation

Translate the scenario into a clear task. Separate facts, assumptions, constraints, and information that is interesting but not relevant to system maps.

Choosing well under real constraints

Applied work is mostly judgement under limits: less time, less information, and more competing goals than a textbook example allows. These are the decision rules that hold up in practice.

• Two approaches both look workable: Choose the one you can test more easily; testability compounds faster than elegance.
• The task feels too large to start: Cut it until one piece can be finished and verified in under an hour, then build outward.
• You are unsure whether something is a real bug: Write the smallest input that reproduces it; if you cannot reproduce it, you cannot claim to have fixed it.

Reading the situation before acting

Before choosing an approach, state three things explicitly: what result the situation actually requires, which constraints are fixed rather than preferences, and what evidence would tell you the approach is working. Skipping this step is the most common reason competent work solves the wrong problem.

• Programs are state changing over time. Most confusion comes from not knowing what a variable holds at a given moment. Reading code as a sequence of state changes, rather than as instructions, is what makes unfamiliar programs understandable.

Compare real options

Generate two workable approaches and test both against the purpose. Do not hide the tradeoff; name what each option improves and what it gives up.

Make the reasoning visible

Produce a working program, configuration, or technical walkthrough and attach a short decision note. The note should make the result auditable, not merely confident.

Use the rubric, not a feeling

Review the work for correct behavior, readable structure, useful tests, and an explained decision. Record evidence for each judgment so feedback points to something observable.

Diagnostic checklist

Run this before you revise anything. Diagnosing first prevents the common failure of polishing the parts that were already fine.

• Check: Changing several things at once when something breaks — is this present in your work?
• Check: Reading code without running it — is this present in your work?
• Check: Treating an error message as noise — is this present in your work?

The quality bar

This is what finished work looks like in this field. Use it as the standard for your revision rather than a general sense of improvement.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Diagnose before editing

Name the symptom, then ask what decision or missing step produced it. Choose the cause you can address rather than changing everything at once.

Revise and compare

Make one purposeful revision and compare the two versions. Keep the change only if it improves the intended result without creating a larger problem.

Define a finishable brief

Choose a specific audience, result, and boundary for the project boss challenges capstone. Reduce scope until the project can be finished and reviewed in one focused cycle.

Bringing the parts together

A capstone is judged on coherence, not on the number of techniques it includes. Return to the core ideas and make sure the work demonstrates them rather than decorating them.

• Programs are state changing over time. Most confusion comes from not knowing what a variable holds at a given moment. Reading code as a sequence of state changes, rather than as instructions, is what makes unfamiliar programs understandable.
• Make it work, then make it clear. Working code that nobody can read becomes unmaintainable within weeks, including for its author. Naming and structure are not decoration; they are how future changes stay cheap.
• A bug is a disagreement between belief and behaviour. Debugging is the process of finding which of your beliefs about the program is false. Printing or inspecting values converts an argument with the computer into an observation.

Standards that make the work credible

These are the marks of work that would be taken seriously by someone who does this professionally.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Build with checkpoints

Plan foundation, first draft, verification, and revision milestones. At each checkpoint, save evidence instead of relying on memory.

Present and continue

Present a working program, configuration, or technical walkthrough with a concise rationale. Use the final rubric to choose one strength to retain and one next practice target.