Teach programming well: diagnose novice misconceptions, use PRIMM, pair programming and Parsons problems, plan standards-aligned units, assess code fairly and navigate teacher certification.

Teaching Computer Science

## Why it matters

Standards tell you, your school and your state what students should know and be able to do at each level. Mapping your units to them helps you justify the curriculum, avoid gaps and repetition across years, and plan with colleagues. In the US, the most widely used reference is the **CSTA K-12 Computer Science Standards**, and at high school many schools also offer **Advanced Placement (AP)** computer science courses from the College Board.

Standards change: CSTA has released revised **PK-12 standards** in 2026 (the first major revision since 2017, with AI integrated throughout), and states adopt, adapt or ignore them on their own schedules. Always check what **your state** has adopted. Official sources: CSTA standards at https://csteachers.org/k12standards/ and AP Central at https://apcentral.collegeboard.org/. Checked on 2026-10-23.

## How the CSTA standards are organised

The 2017 CSTA standards, which many states adopted or adapted, are built on the **K-12 Computer Science Framework** and use this structure:

**Levels** (by grade band):

| Level | Grades |
|---|---|
| 1A | K-2 |
| 1B | 3-5 |
| 2 | 6-8 |
| 3A | 9-10 |
| 3B | 11-12 (often elective) |

**Concepts** (what students learn):

- Computing Systems (CS)
- Networks and the Internet (NI)
- Data and Analysis (DA)
- Algorithms and Programming (AP)
- Impacts of Computing (IC)

**Practices** (how students work): fostering an inclusive computing culture, collaborating, recognising and defining problems, developing and using abstractions, creating computational artifacts, testing and refining, and communicating about computing.

Each standard has an identifier combining level, concept and number, such as **2-AP-13** (level 2, Algorithms and Programming, standard 13). The identifier makes mapping easy: "This unit addresses 2-AP-13 and 2-AP-17."

Check the exact wording of each standard on the CSTA site or in your state's version before you cite it; revised standards may renumber them.

## AP Computer Science

The College Board offers two AP CS courses. Course frameworks, exam formats and required tasks are updated periodically, so read the current Course and Exam Description on AP Central.

| | **AP Computer Science Principles (CSP)** | **AP Computer Science A (CSA)** |
|---|---|---|
| Focus | breadth: creativity, data, the internet, impacts, programming | depth: object-oriented programming |
| Language | teacher's choice (blocks or text) | Java |
| Assessment | end-of-course exam plus a through-course programming project (the Create performance task) | end-of-course exam with multiple choice and free-response coding |
| Audience | designed as an accessible first course | students ready for a programming-intensive course |

Teachers who want to teach an AP course must have their school's course authorised through the **AP Course Audit**, and the College Board offers summer institutes and endorsed curriculum providers (several are free).

## Worked example: mapping a unit

Unit: **"Make a quiz app"** in grade 7, two weeks, block-based or Python.

| Unit activity | Standard (2017 identifiers) | Evidence |
|---|---|---|
| Use variables to keep a score | 2-AP-11 (variables) | score updates correctly in the program |
| Use conditionals and loops for questions | 2-AP-12 (control structures) | program asks several questions and checks answers |
| Break the app into procedures | 2-AP-13 / 2-AP-14 (decomposition, procedures) | at least two named functions |
| Test with classmates and fix bugs | 2-AP-17 (testing and refining) | test log with changes |
| Credit borrowed code and media, comment the program | 2-AP-16 / 2-AP-19 (attribution, documentation) | comments and credits |
| Discuss who might be excluded by the app's design | 2-IC-21 (bias and accessibility) | short reflection |

Treat the numbers above as an example of the method; confirm each code against the version your state uses. Notice that one project covers several standards and both concepts and practices.

## Using standards well

- **Plan backwards:** start from the standards and the evidence you want, then design activities (backward design from the instructional design course).
- **Map across years** with colleagues so students do not do "intro to variables" four times.
- **Do not teach to the identifier.** Standards describe outcomes; your projects should still be engaging.
- **State frameworks may add or rename standards**, and some states fold CS into technology or digital literacy standards.

## Common mistakes

- **Citing standards from memory.** Check the current official wording.
- **Over-mapping.** Claiming 20 standards for one lesson is not credible; pick the ones you assess.
- **Ignoring practices.** Collaboration, testing and communication are standards too.
- **Treating AP as the only goal.** Many students need an engaging first course before or instead of AP.

## Quick recap

- CSTA standards are organised by level, concept and practice, with identifiers like 2-AP-13.
- CSTA released revised PK-12 standards in 2026; check what your state has adopted.
- AP CSP is a broad, accessible course; AP CSA is Java-based programming.
- Map units to a small number of standards you actually assess, and confirm wording on official sites.


Read the CSTA PK-12 standards and the AP Computer Science courses, and map a unit to them.

CSTA standards and AP CS

Overview of the 2026 CSTA PK–12 Standards

AP Computer Science Principles

Write the unit's big question or project brief in two sentences, and the grade level and prior knowledge you assume.

List 2-4 standards the unit will assess (use your state's adopted standards or CSTA) and the evidence for each.

Write the project rubric with 3-4 criteria (for example: works correctly, uses functions, tested, documented) and descriptors for each level.

Lay out the lessons day by day: which concept each introduces (with PRIMM or a worked example) and how it moves the project forward.

Add at least two checkpoints where students show progress (a short demo, a Parsons problem, an exit ticket).

Plan differentiation: one support (starter code, pair programming, a worked example) and one extension for each project stage.

Add the logistics: tools or accounts needed, what happens if a student misses a day, and how work is submitted.

Ask a colleague or friend to read it and say where a student might get stuck. Adjust the plan.

## Why it matters

A single good lesson is not enough; students learn programming through connected practice over weeks. A **unit** is a sequence of lessons (often two to four weeks) building toward a set of outcomes, usually with a project at the end. Planning the whole unit before you start lets you sequence concepts, schedule checkpoints, prepare materials and spot problems early, instead of improvising each night.

## The core idea: plan backwards from the project

**Backward design** (Wiggins and McTighe's *Understanding by Design*) has three stages:

1. **Desired results:** which standards and understandings does the unit target?
2. **Evidence:** how will students show they have reached them? (the project, checkpoints, quizzes)
3. **Learning plan:** which lessons and activities get them there?

Projects are a natural fit for CS: students build something real, and the project itself is evidence. But a project alone is not a plan. Each lesson should teach a concept the project needs and move the project one step forward.

## Anatomy of a two-week unit

| Day | Lesson focus | Project step | Check |
|---|---|---|---|
| 1 | launch: show a finished example, brief, rubric | brainstorm and sketch | exit ticket: what will your app do? |
| 2 | variables and input (PRIMM) | ask one question | |
| 3 | conditionals (worked example) | check the answer, keep score | Parsons problem |
| 4 | loops | ask several questions | |
| 5 | **checkpoint demo** | working core in pairs | quick demo to a peer |
| 6 | functions (worked example, subgoals) | refactor into functions | |
| 7 | lists | store questions in a list | |
| 8 | testing and debugging | test plan, swap with a classmate | test log |
| 9 | polish and documentation | comments, credits, readme | |
| 10 | showcase and reflection | present and reflect | rubric self-assessment |

This structure mixes **direct instruction** (short, with examples), **guided practice** (PRIMM, Parsons) and **project time**, with checkpoints on days 5 and 8.

## Rubrics

A clear rubric shared on day 1 tells students what quality looks like. Keep it short:

| Criterion | Beginning | Developing | Proficient |
|---|---|---|---|
| **Works correctly** | runs with major errors | runs; some features fail | all core features work |
| **Uses functions** | none | one function | logical functions with clear names |
| **Tested** | not tested | some tests | test log with fixes |
| **Documented** | no comments | some comments | comments, credits and a short readme |

Separate **functionality** from **code quality** and **process**, so a student whose app does less but is well tested can still show strong learning.

## Differentiation

Classes include students who have coded for years and students who have never typed a bracket. Plan both ends:

- **Support:** starter code with the structure in place, worked examples to refer to, Parsons versions of a step, pairing.
- **Extension:** extra features with clear specs (a timer, a high-score table, reading questions from a file), or a "challenge card" per stage.
- **Choice:** let students choose the theme of their project (a quiz about their hobby, their language, their community). This supports motivation and inclusion.

## Logistics that save the unit

- Accounts and tools set up and tested **before** day 1.
- A plan for absent students (a catch-up worked example and checklist).
- Clear submission: where, in what format, by when.
- Backup activity for when the network fails (unplugged tracing or Parsons on paper).

## Common mistakes

- **Project with no teaching.** "Build a game" for two weeks leaves many students stuck.
- **Teaching with no project link.** Concepts feel disconnected if they do not appear in the project.
- **No checkpoints.** You discover on day 10 that half the class is lost.
- **Rubric only at the end.** Students cannot aim for criteria they have not seen.
- **Over-ambitious scope.** Plan for the middle of the class; extensions handle the rest.

## Quick recap

- Plan units backwards: results, evidence, then lessons.
- Each lesson teaches a concept and moves the project forward.
- Share a short rubric on day 1 and include checkpoints mid-unit.
- Differentiate with supports, extensions and student choice; prepare logistics in advance.

## Try it

Open the Do tab and plan a two-week project unit.


Plan a two-week CS unit backwards from a project, with lessons, checkpoints and differentiation.

Planning a unit

Teaching CS Fundamentals: Lesson Planning

## Why it matters

Assessment in CS has two jobs: telling students how they are doing so they can improve (**formative**), and recording what they have achieved (**summative**). Programming work is easy to check for "does it run?" and hard to check for "does the student understand it?". Good CS teachers combine automatic testing, human judgement and well-designed tasks to get a fair picture without drowning in marking.

## Autograding: what it is good at

An **autograder** runs student code against test cases and reports what passed. Tools include GitHub Classroom, Gradescope, CodeHS, Runestone and many learning platforms; you can also write a simple one yourself (the Do tab).

Autograders are good at:

- **Correctness on specified inputs:** does `average(2, 4)` return 3?
- **Fast feedback:** students can test, fix and resubmit many times.
- **Consistency:** every submission is checked the same way.
- **Scale:** 150 submissions take seconds.

## What autograders miss

- **Design and readability:** names, structure, comments, duplication.
- **Understanding:** a student may have copied or generated code they cannot explain.
- **Partial progress:** a program that fails one test may show more learning than one that passes by accident.
- **Edge cases you did not think of:** tests only check what you wrote.

So combine autograded tests with a short rubric for quality and process, and with ways to check understanding (see below).

## Writing good test cases

- **Typical cases:** the ordinary inputs (`average(2, 4)`).
- **Boundary cases:** zero, empty lists, one item, the largest allowed value.
- **Tricky cases** linked to misconceptions: integer vs float results, off-by-one ranges, negative numbers.
- **Clear names:** "handles an empty list" tells a student more than "test 4".
- **Hidden and visible tests:** show some tests so students can work toward them, keep a few hidden to discourage hard-coding answers.

## Worked example: feedback that teaches

A student's function:

```python
def average(a, b):
    return a + b / 2
```

A bare autograder says: `1/3 tests passed`. A better one says:

> 1 of 3 tests passed. First failure: inputs (2, 4), expected 3, got 4.0

That message points at the bug (operator precedence: `b / 2` happens first) without giving away the fix. You can add **hint messages** to specific tests: "Check the order of operations: does division happen before addition?".

## Checking understanding

Because code can be copied, shared or generated by AI tools, many teachers add:

- **Code explanations:** a short written or spoken explanation of how their code works.
- **Modify-on-the-spot tasks:** "change your function so it averages three numbers" in class.
- **Code reading questions** on tests: tracing, predicting output, finding a bug.
- **Process evidence:** commit history, test logs, planning notes.

Be clear about your policy on collaboration and AI tools, and design tasks where the learning is visible.

## Grading fairly

- Separate **correctness**, **quality** and **process** in your rubric.
- Allow **resubmission** for formative work: the goal is learning, not one shot.
- Check that your tests are **correct** and **fair** before releasing them (run them on your own solution and on a deliberately buggy one).
- Watch for bias: do students who had coding at home score higher on "polish" criteria that you never taught?

## Common mistakes

- **Only autograding.** Students learn to satisfy tests, not to write good code.
- **Only hidden tests.** Students cannot tell what is expected.
- **Unhelpful messages.** "Test 3 failed" teaches nothing.
- **Tests that crash on student errors.** A good grader catches exceptions and reports them.
- **Grading what you did not teach.** If style counts, teach and model it first.

## Quick recap

- Autograders give fast, consistent feedback on correctness; they miss design and understanding.
- Write typical, boundary and misconception-based tests with clear names and useful messages.
- Combine tests with a quality rubric and checks of understanding.
- Allow resubmission, verify your tests, and be clear about collaboration and AI policies.

## Try it

Open the Do tab and write a small autograder that runs test cases and produces student feedback.


Assess programming work fairly with autograded tests, rubrics and useful feedback.

Assessing code

Creating a Programming Assignment

GitHub Classroom: Getting started

Map units to the CSTA standards and AP Computer Science courses, plan a two-week project unit, and assess code with autograded tests and feedback.