Think first.
Code second.

You'll set up your full development environment, write your very first program, and make your first commit to GitHub. We spend time on the question: what is actually happening when code runs? You write down something you want to build by the end of the year.

We see the whole system — browser → Flask → database → response — just so you know it exists. You don't build this yet; you just trace the path on paper. Then we focus on the Python fundamentals you will build yourself.

You write everyday decisions in English before translating to Python. The key habit here: predict what the output will be before you run it. A bug you fix by trial-and-error without understanding why isn't actually fixed.

Debugging means reading the error, forming a hypothesis, and testing it — not randomly changing things until something works. We practice this deliberately.

Big conceptual shift this week: a function that only prints is like a calculator that shows the answer but won't let you use it in another calculation. On Thursday, before writing any code for your personal program, you write a one-sentence scope statement and get it approved.

AI becomes available — but with a protocol. Before asking AI anything, you write: what you're trying to do, what you've already tried, and your best guess at a solution. Then you log what AI said and whether it was actually correct. Note: 4-day week, PD day Friday.

You complete one full design cycle at very small scale. Not to produce a polished product — just to feel the shape of the cycle so Unit 2 isn't your first time. Friday: you read the pathway options and annotate two you're considering.

The code-reading challenge gives you 10 minutes of silent reading before any discussion. Can you understand code you've never seen before? This is evidence of a real mental shift. You also complete your oral desk check — a short conversation where you explain a few lines of your personal program.

Before writing a line of code, you need a clear, specific problem. Not "students need a better app" — but "Grade 9 students in advisory need a way to track homework deadlines across three systems." You research what already exists and what it doesn't do.

This is a significantly disrupted week (UN Day on Tuesday, Parent–Teacher Conferences Wednesday–Thursday). Two full school days only. Use the time for independent research on your pathway problem. The Criterion A design brief is due the Monday after break.

You cannot begin coding until your design document has been reviewed and approved by the teacher. This is a hard gate — no exceptions. The scope statement (one sentence: what the core does; one thing explicitly out of scope) is required before approval.

Build the core. Every other feature is optional until the core works and is tested. The desk check question every day is: "Is your core working? Show me." Your AI log is graded for the first time this Friday.

A partner will run your program and give feedback. You'll also analyze a short AI-generated program containing deliberate bugs — can you spot what's wrong before running it?

3-day week only — Thanksgiving Thursday and Friday. Get to a submittable version by Wednesday. Oral defense sign-ups open this week.

You defend your code in a 5-minute conversation. The question sequence is posted in advance — this is scaffolded, not a surprise. No further commits after Monday's deadline.

A dictionary is a list of labelled boxes. We compare the same student data represented as a list of lists versus a list of dicts — which is easier to work with? The question at the end of the week: "What if you had a million records?"

No AI this week. You write SQL queries on paper before running them. This raw understanding is essential — next month, when SQLAlchemy generates SQL for you automatically, you'll understand exactly what it's doing because you did it yourself first.

Wednesday is a big moment: we show the same query in raw SQL and in SQLAlchemy side by side. You identify which part of the ORM maps to which SQL clause. The question we'll argue about: "If these produce the same result, why use the ORM?"

You choose a real question, query a real dataset in both raw SQL and SQLAlchemy, verify they match, and write about what the data shows — not just what the code does. Semester 1 ends Friday.

50 lines of code you've never seen. 10 minutes of silent reading. Can you annotate what each section does, predict what happens on a given input, and identify a design decision? This is a readiness check for Unit 4. Semester 2 begins Monday.

Full AI access — but you start by generating project ideas on paper, without AI. The first draft of your criteria is yours: what would excellent, good, and not yet look like for your specific project?

Your design must be specific enough that a classmate could implement from it. Peer check: swap documents — can your partner explain what you're building? Criteria must be measurable, not aspirational.

Your approved design is your contract. Daily question: "Am I building what I designed, or have I drifted?" Students building optional features before the core is working get redirected immediately.

4-day week (PD Day Monday). After two weeks away, you re-read your design doc and commit history before writing a single new line. You'll present to someone on a different pathway: their fresh perspective often catches what you've stopped seeing.

You test your project against the criteria you designed. Honest self-assessment: which criteria does it meet? Where does it fall short? What's the evidence?

Different partner from Round 1. Focus: "What has changed since Round 1? What feedback did you act on?" You document three specific test cases — not just "it works."

3-day week (P-T Conferences Thu–Fri). The program must be in a submittable state by close of Wednesday. If you've scope-crept, today is the day to cut features gracefully and document what was cut and why.

You defend your code live. Mode 3 means you had full AI access — which means you need to be able to explain every decision, including the ones AI suggested. The hardest questions will be about AI-generated code.

The capstone proposal is the most rigorous Criterion A document you'll produce. Your stakeholder must be a specific named person — not "teachers" or "students" but a real individual whose input changes your design. Something you learn from talking to them must show up in your proposal.

Write one sentence: "This project will NOT include…" Something must be out of scope. If nothing is, you haven't scoped it. Define done before you start.

By May 14 (Integration Checkpoint), all major components must be connected. A 60% done product that works is better than a 100% planned product that can't be demonstrated. After the checkpoint passes, extension features can begin.

You practice the 10-minute defense with a partner. Identify 3 things in your code you could be asked to modify live — and practice each modification at least once. Prepare a 5-minute non-technical version for the authentic audience.

The 10-minute defense includes a live code walkthrough and a modification challenge — you'll be asked to change something in your code on the spot and explain the effect. The authentic audience presentation (parents, teachers, other students) is a 5-minute non-technical version: what you built, why it matters, who it helps.