This course is for people who want to teach computer science in middle school, high school, college or community settings. The first module covers CS pedagogy: the misconceptions novices really have about variables, loops and functions, structured approaches such as PRIMM and pair programming, and Parsons problems and worked examples that reduce overload for beginners. The second module turns that into curriculum: reading the CSTA standards and the AP Computer Science courses, planning a two-week unit around a project, and assessing code with autograded tests plus human feedback. The third module is about the classroom itself: inclusive and culturally responsive practice, setting up a class on a free platform, and an honest map of the qualifications you need. Teaching in a K-12 public school in the United States normally requires a bachelor's degree and a state teaching licence or computer science endorsement, and requirements vary by state; teaching at college level usually requires a master's or doctorate. The course links to official sources (CSTA, the College Board and state education departments) instead of copying rules that change.

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

When a student's program is wrong, it is tempting to fix the line and move on. But most novice errors are not typos: they come from a consistent, wrong mental model of how the computer works. Fix the line and the model stays; the same error comes back next week in a different form. Good CS teachers learn to read a wrong answer as evidence of **what the student believes**, then target that belief.

## The core idea: notional machines

Researchers use the term **notional machine** for the simplified model of the computer that a teacher wants students to hold: "a variable is a named box holding one value", "the program runs one line at a time, top to bottom, unless a loop or call sends it elsewhere". Misconceptions are gaps or errors in that model. Making the notional machine explicit (with diagrams, tracing tables and visualisers) is one of the most effective things you can do.

## Common misconceptions and how they show up

| Misconception | What the student believes | Typical evidence |
|---|---|---|
| **Assignment as equation** | `a = b` links `a` and `b` forever | expects `a` to change when `b` changes later |
| **Variables hold history** | a variable remembers all its past values | traces show several values in one box |
| **Order does not matter** | the computer reads the whole program and "understands" it | uses a variable before assigning it |
| **The computer knows what I mean** | names carry meaning (`largest` will find the largest) | names a variable and expects behaviour |
| **Print equals return** | showing a value is the same as giving it back | function prints but caller gets `None` |
| **`if` loops** | an `if` repeats like `while` | expects an `if` body to run many times |
| **Loop runs once more / less** | unclear about where `range` stops | off-by-one errors on boundaries |
| **`=` vs `==`** | the symbols are interchangeable | assignment inside a condition (in languages that allow it) |

## Worked example: diagnosing from code

A student writes this to swap two values:

```python
a = 5
b = 9
a = b
b = a
print(a, b)   # student expects: 9 5
```

The output is `9 9`. Possible beliefs behind it:

1. **Assignment as equation or simultaneous:** the student thinks both lines happen "at once", like swapping in maths.
2. **Variables hold history:** they think `a` still "remembers" 5 after `a = b`.

A good diagnostic question separates them: *"After line 3, what is in `a`? Is 5 stored anywhere?"* A student who says "5 is still in `a` as well" has the history misconception. Then you address the model, not just the code: trace line by line in a table, one row per line, one column per variable.

| line | a | b |
|---|---|---|
| 1 | 5 | - |
| 2 | 5 | 9 |
| 3 | 9 | 9 |
| 4 | 9 | 9 |

Only after the model is fixed do you introduce a temporary variable (`temp = a`).

## Worked example: print vs return

```python
def double(n):
    print(n * 2)

result = double(4) + 1
```

The program shows `8` and then crashes with `TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'`. The student is confused: "But it printed 8!" The misconception is that printing gives a value back. Ask: *"Where does 8 go when it is printed? Where does the value go when it is returned?"* A picture of the screen versus the caller helps.

## Teaching moves that help

- **Predict before run.** Ask students to predict output before running code. Wrong predictions surface misconceptions quickly.
- **Trace tables and visualisers.** Python Tutor (pythontutor.com) shows variables and frames step by step.
- **Diagnostic multiple-choice questions** where each wrong answer matches a known misconception, so the choice tells you the belief.
- **Refutation.** Show a case where the wrong model predicts something different from what happens, then explain why.

## Common mistakes (for teachers)

- **Fixing the code for the student.** You remove the evidence and keep the misconception.
- **Assuming it is carelessness.** Consistent errors usually mean a consistent model.
- **Explaining with too much abstraction.** "Memory addresses" can confuse beginners; start with boxes and arrows.
- **Ignoring language effects.** `=` reads as "equals" in maths. Say "gets" or "is assigned" aloud.

## Quick recap

- Most novice errors come from wrong mental models, not typos.
- Make the notional machine explicit with tracing tables and visualisers.
- Learn the common misconceptions: assignment as equation, print vs return, `if` as loop, off-by-one.
- Diagnose with targeted questions and predictions before you correct.


Recognise the most common novice programming misconceptions and diagnose them from a student's code.

Common novice misconceptions

"How to teach programming (and other things)?" by Felienne Hermans

Java NM - Example 1: Two int variables are independent and do not become linked

Write one learning objective in student language, such as 'I can predict how many times a for loop runs'.

Write a short Predict program (5-10 lines) that uses the concept, and the question students answer before running it.

Plan Run: how students will run it (a free online editor or the school's tool) and compare output with their prediction.

Write three Investigate questions that make students trace, annotate or change one value and explain the effect.

Write a Modify task that changes the program's behaviour slightly (for example, count down instead of up).

Write a Make task that uses the concept in a new program, with an extension for fast finishers.

Decide which stages are done in pairs. Write the driver/navigator role cards and when students swap (every 5-10 minutes).

Add timings for each stage so the plan fits 50 minutes, and one exit question to check the objective.

## Why it matters

Many beginner programming lessons jump straight to "write a program that...". For novices this is like asking someone to write an essay in a language they have only heard spoken. They stare at a blank editor, copy something from the internet, or give up. Two well-researched approaches give students a gentler, more structured path: **PRIMM** for lesson structure and **pair programming** for collaboration.

## PRIMM: read before you write

PRIMM was developed by Sue Sentance and colleagues in England. It moves students from reading code to writing it in five stages:

| Stage | Students... | Teacher's role |
|---|---|---|
| **Predict** | read a short program and predict its output, without running it | choose code that uses the new concept in a familiar context |
| **Run** | run it and compare with their prediction | discuss surprises; misconceptions surface here |
| **Investigate** | trace, annotate, answer questions, change one thing and observe | ask targeted questions about each line |
| **Modify** | change the program to do something slightly different | scaffold from small to larger changes |
| **Make** | write a new program that uses the concept | provide a clear task and an extension |

The key idea is that **reading and understanding code comes before writing it**. Students get a working example to reason about, so their first experience is success, not a blank screen. The approach also gives you natural checkpoints: if many predictions are wrong, you stay longer on Investigate.

## Worked example: a PRIMM lesson on `for` loops

**Predict:**

```python
total = 0
for n in range(1, 4):
    total = total + n
print(total)
```

"What will this print? Write your answer before running it." Common predictions: 6 (correct), 10 (thinking `range` includes 4), or 3 (thinking the loop runs once).

**Run:** students run it and compare. Discuss why `range(1, 4)` gives 1, 2, 3.

**Investigate:**
1. Add a `print(n, total)` inside the loop. What do you see?
2. What would `range(1, 6)` print? Predict, then check.
3. What happens if `total = 0` is moved inside the loop? Why?

**Modify:** make it add only even numbers from 2 to 10.

**Make:** write a program that multiplies the numbers 1 to 5 (5 factorial), then an extension: ask the user for `n`.

## Pair programming: two people, one problem

In **pair programming**, two students work on one computer:

- The **driver** types and focuses on the current line.
- The **navigator** reads, checks, thinks ahead and suggests.
- They **swap roles** regularly, often every 5-10 minutes, with a timer.

Studies in university and school settings have linked pair programming with better completion rates, more confidence and better retention, including for students under-represented in computing. It also reduces the number of "I'm stuck" hands, because pairs solve many problems themselves.

## Making pairing work

Pairing fails when one student does everything. Structure helps:

- **Role cards** on the desk describing what each role does and says.
- **A visible timer** and a clear signal to swap.
- **Talk norms:** the navigator suggests, does not grab the keyboard; the driver explains what they are typing.
- **Thoughtful pairing:** pair students of similar confidence where possible, and change pairs between units.
- **Individual accountability:** short individual exit questions so you can still see what each student understands.

PRIMM and pairing combine well: pairs predict and investigate together, then each student does a short individual Make task.

## Common mistakes

- **Skipping Predict.** Running code first removes the moment where misconceptions show.
- **Investigate questions that only ask "what does it print?"** Ask "why?" and "what if?" too.
- **Unstructured pairs.** Without roles and swaps, the more confident student drives the whole time.
- **No individual check.** Pairs can hide a student who has not understood.

## Quick recap

- PRIMM = Predict, Run, Investigate, Modify, Make: read and reason about code before writing it.
- Predictions surface misconceptions; Investigate questions deepen understanding.
- Pair programming uses driver and navigator roles with regular swaps.
- Structure pairing with role cards, timers and individual exit checks.

## Try it

Open the Do tab and plan a 50-minute PRIMM lesson that uses pair programming.


Plan a PRIMM lesson and run structured pair programming with clear roles.

PRIMM and pair programming

reWatch: PRIMM for Teaching Programming w/ Andy Colley

Teaching CS Fundamentals: Pair Programming

## Why it matters

Writing a program from scratch asks a novice to do many things at once: recall syntax, choose a plan, remember variable names, and track what the code does. **Cognitive load theory** explains why that overloads beginners: working memory can hold only a few new items at a time. Two techniques with strong research support reduce that load while keeping students thinking: **worked examples** and **Parsons problems**.

## Worked examples

A **worked example** is a complete, step-by-step solution that students study before solving similar problems themselves. Research across maths and programming (often called the *worked-example effect*) shows that beginners learn more from studying good examples than from solving the same number of problems unaided.

Make worked examples more effective by:

- **Pairing each example with a practice problem** that has the same structure but a different context.
- **Subgoal labels:** short headings that name the purpose of each chunk of code. Lauren Margulieux and colleagues found that labelled examples improve transfer to new problems.
- **Fading:** first a full example, then one with a step missing, then two, until students write the whole thing.
- **Self-explanation prompts:** "Why does this line come before the loop?"

```python
# Subgoal: set up a counter
count = 0
# Subgoal: look at each item
for score in scores:
    # Subgoal: test the condition
    if score >= 50:
        # Subgoal: update the counter
        count = count + 1
# Subgoal: report the result
print(count)
```

The subgoals ("set up a counter, look at each item, test, update, report") are a reusable plan students can apply to "count the words longer than five letters" next.

## Parsons problems

A **Parsons problem** (introduced by Dale Parsons and Patricia Haden in 2006) gives students the correct lines of a program in scrambled order. Students drag them into the right order and, in some versions, the right indentation.

Why they work:

- Students focus on **logic and order**, not syntax recall or typing.
- Every attempt uses correct syntax, so they see good code.
- They are quick to solve and quick to check automatically.
- Barbara Ericson's research found Parsons problems can produce similar learning to writing the same code, in less time.

Variations:

- **Distractors:** extra lines that are plausible but wrong (an off-by-one `range`, `=` instead of `==`). Choose distractors that match common misconceptions, so a wrong choice is diagnostic.
- **Indentation required:** students must also indent correctly, which tests understanding of blocks.
- **Faded Parsons:** some lines have blanks to fill in, as a bridge to writing code.
- **Adaptive Parsons:** the tool combines blocks or removes distractors after repeated failures (Runestone Academy supports this).

## Worked example: designing a Parsons problem

Goal: practise the accumulator pattern.

1. Write a correct solution of 5-8 lines (longer ones get frustrating).
2. Split it into blocks, one line each (or two lines that always go together).
3. Add one or two distractors based on misconceptions you have seen: for example `count = 0` inside the loop.
4. Decide whether indentation is part of the puzzle.
5. Write the checking rule: exact order, or any order that produces correct output (some lines can be swapped legally).
6. Test it on a colleague and time it: 2-5 minutes is a good target.

Free tools include Runestone Academy and js-parsons; you can also do them on paper strips.

## Common mistakes

- **Examples without practice.** Studying examples helps only when followed by similar problems.
- **Too many distractors.** One or two is enough; more turns the puzzle into guesswork.
- **Only one correct order when others work.** If two lines can be swapped, accept both or redesign.
- **Using Parsons forever.** They are a bridge. Fade toward writing code independently.

## Quick recap

- Beginners have limited working memory; worked examples and Parsons problems reduce load.
- Use subgoal labels, fading and self-explanation with worked examples.
- Parsons problems scramble correct code; distractors should match real misconceptions.
- Keep puzzles short, check alternate valid orders, and fade toward independent writing.

## Try it

Open the Do tab: solve a Parsons problem, add a distractor and write the shuffle and grading functions.


Use worked examples, subgoal labels and Parsons problems to reduce cognitive load for novice programmers.

Parsons problems and worked examples

Teaching coding: What is a Parsons problem?

Worked Examples | A Simple Way To Accelerate Student Learning

Diagnose common novice misconceptions, plan lessons with PRIMM and pair programming, and use Parsons problems and worked examples.

CS Pedagogy

## 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.

Curriculum and Standards

## Why it matters

Computing has long had unequal participation. In many countries, girls, students from some racial and ethnic groups, students from low-income families and students with disabilities are under-represented in CS classes and careers. Much of that gap comes from **access** (whether a school offers CS at all) and **belonging** (whether students believe "people like me do this"). A teacher cannot fix every structural problem, but classroom choices make a measurable difference to who enrols, who persists and who succeeds.

## The core idea: belonging and relevance

Two ideas run through the research and frameworks:

- **Belonging:** students who feel they belong in a subject work harder and persist through difficulty. Stereotypes ("CS is for boys", "you need a geek gene") undermine that. There is no evidence for a fixed programming aptitude; skill comes from practice and good teaching.
- **Relevance:** students engage more when projects connect to their lives, communities and interests.

**Culturally responsive** (or culturally relevant) teaching builds on students' cultures, languages and experiences as assets, not obstacles. The **Kapor Center** published a Culturally Responsive-Sustaining CS Education Framework, and CSTA's standards include "fostering an inclusive computing culture" as a core practice.

## Practices that help

**Classroom culture**

- Normalise struggle: bugs are a normal part of programming, not a sign you are bad at it. Share your own bugs.
- Praise strategies and effort ("you traced it line by line") more than speed or "being smart".
- Set norms for help-seeking and for talking about each other's code respectfully.
- Watch for dominance: who answers, who types, who gets interrupted. Use structured turn-taking and pair roles.

**Curriculum and projects**

- Offer project themes with choice: a quiz about students' own interests, a data project on a local issue, an app for a community group.
- Show a wide range of people in computing: examples, guest speakers, case studies.
- Discuss the **impacts of computing**: biased algorithms, accessibility, privacy. Students who see CS as relevant to justice and community are often more motivated.

**Access and accessibility**

- Use tools that work on school devices and low-bandwidth connections; avoid tasks that need a home computer.
- Apply **Universal Design for Learning (UDL)**: multiple ways to learn (video, text, examples), to engage (choice) and to show learning (demo, writing, code).
- Check tools for accessibility: screen reader support, keyboard navigation, colour contrast, captions. Block-based tools vary in screen-reader support.
- Support multilingual learners with visual examples, glossaries and allowing discussion in home languages.

**Recruitment**

- Personally invite students who might not see themselves in CS; personal encouragement from a teacher is a strong factor in enrolment.
- Look at your enrolment data by group and ask counsellors to check placement practices.

## Worked example: rewriting a project brief

Original: *"Build a game where you shoot asteroids. Bonus points for the most explosions."*

Problems: one narrow theme that some students find unappealing; competition on a single measure.

Revised: *"Build an interactive program for someone you know: a game, a quiz, a story or a tool. It must use variables, conditionals and at least one loop. Write two sentences about who it is for and why it would help or delight them."*

The technical requirements are the same; the space for students' identities and interests is much larger.

## Common mistakes

- **Treating inclusion as a one-off lesson.** It is a set of everyday practices.
- **Tokenism:** a poster of a famous woman in computing without changing who participates in class.
- **Assuming access:** homework that requires a laptop and Wi-Fi at home.
- **Calling students "naturals".** It implies others are not, and reinforces the fixed-ability myth.
- **Ignoring disability:** accessible tools and flexible deadlines are part of inclusion.

## Quick recap

- Participation gaps in CS come largely from access and belonging.
- There is no fixed "programming gene"; teach that skill grows with practice.
- Use relevant, choice-based projects, structured collaboration and visible role models.
- Design for access and accessibility (UDL, school devices, accessible tools) and recruit actively.


Apply culturally responsive and inclusive practices so every student can belong and succeed in computing.

Inclusive CS classrooms

Equity in Computer Science

Culturally relevant pedagogy in the computing classroom | Computing education research

Create a free teacher account on Code.org (or the platform you chose) with a professional email address.

Create a class section with a test name (for example 'Practice Period 1') and choose a grade band.

Assign one course or unit to the section and look through the first lesson's teacher materials.

Find how students join (section code, picture or word passwords for young students) and write those instructions as a one-page handout.

Join your own section as a pretend student in a private browser window using an invented name, and complete one activity.

Back in the teacher view, find the progress dashboard and locate your pretend student's work.

Write down your school or district's rules for approving student data tools (US examples: FERPA, COPPA, state privacy laws), and who to ask before using the tool with real students.

Delete the pretend student or archive the practice section when you are done.

## Why it matters

The right tools let students start coding in minutes and let you see their progress at a glance. The wrong ones eat lessons with login problems, installation failures and blocked websites. Choosing and setting up tools is a real part of a CS teacher's job, along with protecting students' data.

## The main kinds of tools

| Kind | Examples | Good for |
|---|---|---|
| **Block-based environments** | Scratch, Code.org App Lab and Sprite Lab, MakeCode | younger students and first courses; no syntax errors |
| **Curriculum platforms with sections** | Code.org, CodeHS, Runestone Academy (CS Awesome for AP CSA) | full courses with lessons, teacher dashboards and progress tracking |
| **Browser code editors** | Python Tutor, online editors built into platforms | quick text-based practice without installs |
| **Local editors** | Thonny (Python for beginners), IDLE, VS Code | older students, offline use, real-world workflow |
| **Assignment and grading** | GitHub Classroom, Gradescope, your LMS (Google Classroom, Canvas) | distributing starter code, autograding, collecting work |
| **Physical computing** | micro:bit, Raspberry Pi, Arduino | engagement, connecting code to the physical world |

Many of these have free tiers or are free for teachers. Features, pricing and age limits change, so check each provider's current education terms before planning around them.

## Choosing tools: questions to ask

1. **Does it fit the course?** Language, level and standards.
2. **Does it run on our devices?** Chromebooks, tablets, locked-down school laptops, slow networks.
3. **What does it cost now and later?** Is the free tier enough for a whole year?
4. **How do students log in?** Single sign-on with school accounts saves lessons.
5. **What student data does it collect?** Is it approved by the school or district?
6. **Is it accessible?** Screen-reader and keyboard support, captions, contrast.
7. **What is the backup?** If the service is down, can you teach the lesson unplugged?

## Student data and privacy

Teachers are responsible for using tools their school allows. In the US, relevant laws include **FERPA** (student education records), **COPPA** (online services and children under 13) and many state student-privacy laws; other countries have their own (for example GDPR in the UK and EU). Practically:

- Use tools your school or district has approved, or ask your technology coordinator before signing students up.
- Prefer platforms that let students join a teacher section without personal email addresses.
- Do not upload student work or names to tools that are not approved.
- Know how to delete student accounts and data at the end of the year.

## Worked example: first-week setup checklist

For a new middle-school class using Code.org:

1. Teacher account created with school email; section created per class period.
2. Students join with a section code; younger students use picture passwords.
3. Course assigned to each section; teacher previews lesson 1 as a student.
4. Login cards printed for each student and a copy kept securely.
5. Test on a school device with the school network, including the student login flow.
6. Unplugged backup activity ready for day 1 in case the network fails.
7. Parent or guardian letter sent explaining the tool, if the school requires it.

## Managing the room

- Use the **teacher dashboard** to spot students who are stuck (no progress) during the lesson, not just after.
- Ask students to put screens down or lids half-closed during instructions.
- Keep a "three before me" rule: check notes, ask a partner, check the hint, then ask the teacher.
- Have an extension task ready so fast finishers do not drift.

## Common mistakes

- **Testing only on your own laptop.** School devices and networks often block things.
- **Signing up students before approval.** Privacy rules exist for good reasons.
- **Changing tools every unit.** Each new tool costs a lesson of setup and confusion.
- **No backup plan.** Platforms go down; unplugged activities save the lesson.
- **Ignoring the end of the year.** Archive work, export what students want to keep and remove accounts.

## Quick recap

- Choose tools for fit, devices, cost, login, privacy, accessibility and backup.
- Many good platforms are free for teachers; check current education terms.
- Use approved tools and follow your school's privacy rules (FERPA, COPPA, state law in the US).
- Test the full student flow on school devices before day 1 and keep an unplugged backup.

## Try it

Open the Do tab and set up a practice class section on a free platform.


Choose free classroom platforms and set up a class section safely and practically.

Classroom tools

Getting Started with CodeAI: Creating a Classroom Section

Decide the setting you are aiming for: public K-12, private or charter school, community college, university, or informal teaching (bootcamps, after-school clubs).

For K-12 in the US, open your state department of education's educator certification page (search '<your state> department of education educator certification'). Record whether the state has a computer science licence, a CS endorsement or allows CS under another subject.

Record the requirements: degree, teacher preparation programme, subject test (some states use a Praxis Computer Science test), background check, and any student-teaching hours.

Look for alternative or career-changer routes on the same official site, and note their conditions (for example teaching on a provisional licence while completing a programme).

If you already hold a licence in another subject, find out how to add a CS endorsement. If you hold a licence from another state, check reciprocity on the official site.

For college teaching, read three current job postings for CS instructors or lecturers near you and record the degree they require (often a master's for community colleges, a doctorate for many university faculty roles).

Check CSTA (csteachers.org) for your local chapter and professional development, and the College Board's AP Central if you plan to teach AP.

Write a one-page route plan with each step, the official link, the date you checked it, and an estimated time and cost.

## Why it matters

You can learn to teach CS well on this platform, but **where and whom you may teach is set by law and by employers**, not by skills alone. Requirements differ by country, by US state, and by the kind of institution. Planning your route early avoids surprises such as discovering that your state has no CS licence and you need a different subject first, or that a college role requires a graduate degree.

Requirements change often. This lesson explains the common patterns and points to official sources; always confirm the details for your location. Checked on 2026-10-23.

## Teaching K-12 in a US public school

In most US states, teaching in a public school requires:

1. **A bachelor's degree.**
2. **Completion of a state-approved teacher preparation programme** (traditional, through a university, or an alternative route).
3. **A state teaching licence or certificate**, usually with a subject area and grade band.
4. **Subject knowledge tests** where the state requires them. Some states use a Praxis Computer Science test from ETS (https://www.ets.org/praxis); others use their own exams or none.
5. **Background checks** and sometimes student-teaching hours.

For computer science specifically, states take different approaches:

- some offer a **dedicated CS licence or certification**;
- some offer a **CS endorsement** added to an existing licence (for example mathematics or business);
- some allow CS to be taught under another licence area, sometimes with extra training;
- requirements may differ for middle school and high school.

The authoritative source is your **state department of education's educator certification office**. Search "<your state> department of education educator certification" and use the official .gov site. CSTA (https://csteachers.org) publishes advocacy and policy resources and has local chapters that can tell you how things work in your state.

**Alternative certification** routes let career changers with a bachelor's degree start teaching sooner, often on a provisional licence while completing a programme. Conditions, costs and timelines vary widely by state.

**Moving between states:** licences do not automatically transfer. Many states have reciprocity agreements (NASDTEC, https://www.nasdtec.net, coordinates the interstate agreement), but you may still need extra tests or courses.

## Private, charter and other schools

Private schools often do not require a state licence, and some charter schools have more flexibility; many still prefer or require one. Read job postings in your area to see what employers actually ask for.

## Teaching at college or university

O*NET classifies postsecondary computer science teachers (25-1021.00) in Job Zone 5: extensive preparation.

- **Community colleges** usually require at least a **master's degree** in computer science or a closely related field (often with a minimum number of graduate CS credits).
- **Universities:** tenure-track faculty generally need a **PhD**. Teaching-focused roles (lecturer, teaching professor) may accept a master's with strong teaching experience at some institutions.
- No teaching licence is required, but teaching experience (graduate teaching assistant work, adjunct roles) matters a lot.

## Outside the US

Most countries have a national or regional teacher registration system; for example, in England teachers in state schools typically hold Qualified Teacher Status, and many countries require a teaching qualification plus a subject degree. Check the official education ministry or teacher registration body for your country.

## Informal and adjacent routes

Not every CS teaching job needs a licence: bootcamps, after-school clubs, libraries, online tutoring, corporate training and nonprofits all hire CS educators. These can be good ways to gain experience while you work toward certification. The technical trainer path on this platform overlaps here.

## Worked example: a career changer's plan

Sam has a bachelor's in business and works as a data analyst. Goal: teach high-school CS in their state.

1. Official state site shows a CS endorsement exists; a full licence is needed first.
2. State offers an alternative route for degree holders: one-year programme, provisional licence while teaching.
3. A subject test is required for the endorsement.
4. Plan: apply to the alternative route programme, take the subject test, join the local CSTA chapter, and volunteer at an after-school coding club to gain classroom experience.

Every step has an official link and a "checked on" date in Sam's plan.

## Common mistakes

- **Relying on forums or old articles.** Use the official state or national site.
- **Assuming one state's rules apply elsewhere.**
- **Ignoring experience.** Schools value classroom experience; start volunteering or tutoring early.
- **Forgetting renewal.** Most licences need professional development hours to renew.

## Quick recap

- US public K-12: bachelor's degree, teacher preparation, a state licence, and often a CS licence or endorsement; rules vary by state.
- College teaching: usually a master's (community college) or a PhD (university faculty).
- Use official sources (state education departments, CSTA, ETS, NASDTEC, AP Central) and record the date checked.
- Informal teaching roles can build experience while you qualify.

## Try it

Open the Do tab and map your own certification route using official sources.


Map the degree and certification routes to teaching computer science in K-12 or college in your state or country.

Teaching licensure and degrees

Become A Computer Science Teacher

CS Teacher Certification Showcase + Teacher Panel

Build an inclusive CS classroom, set up a class on a free platform, and map the degree and certification routes for where you want to teach.

Teaching Computer Science

About this course

Course content

CS Pedagogy

Curriculum and Standards

Classroom Practice

Where this course leads

Careers that use it