FND-102 Instructor Guide

For instructors and homeschool parents running FND-102. The course is self-runnable from the student-facing materials; this guide adds pacing context, common stumbling blocks, and grading guidance.

Course shape at a glance

Cohort pacing recommendations

• Self-paced (one student): 14 calendar weeks is comfortable. Students with prior Python may move through weeks 1-3 faster; do not let them skip the lab artifacts.
• Homeschool (1-3 students, parent-led): 14 weeks at 1 module per week works well. Lectures run as discussions over the code; labs work side-by-side at the same computer.
• Classroom (10+ students): 14-16 weeks. Add a weekly lab session where students debug each other's code; peer help is especially valuable in weeks 3-4 (functions, mutability) and week 9 (debugging).
• Bootcamp (full-time, ~4 weeks): 125 hours fits in 20 working days at 6-7 hours/day. Aggressive but achievable. Use Saturday review sessions for the midterm-prep block.
• Night class (working-adult cadence): 2 evenings per week + Saturday morning lab. Over 14 weeks the per-week shape stays close to the standard but Saturday catches whatever the weekday evenings left unfinished.

Per-week pacing notes and common stumbling blocks

Week 1: Python syntax (variables, types, strings)

Pacing: the first lecture is heavier than later weeks because students are also adjusting to running Python from the terminal. Expect ~60 min for the install verification + first python3 REPL session before any lecture material lands.

Common blocks:

• Students who type python instead of python3 on macOS get the system Python 2 (which is gone in macOS 13+ but persists in students' muscle memory from tutorials). Always: python3.
• "Why are there single AND double quotes?" Both work; pick one and be consistent in a file. The PEP 8 style guide does not mandate one over the other (https://peps.python.org/pep-0008/#string-quotes); the practical answer for the course is "use whichever is convenient and avoid mixing within one line."
• input() returns a string. Students who write if input() == 5 are confused when it never matches. Always convert: if int(input()) == 5.

What to watch: students who finish Lab 1 (temperature converter) without converting input() to a number got lucky with the test cases. Have them run python lab-1-temp.py and type not-a-number; the crash is the teachable moment.

Week 2: Control flow

Pacing: if / else are quick (most students have intuition from other contexts). while and for need the full lecture time. The distinction between for i in range(10) and for item in list is non-obvious; both lectures should reinforce that for walks any iterable.

Common blocks:

• Infinite loops in Lab 2 (guess-the-number) when students forget to decrement a counter inside a while loop. Teach Ctrl-C as a survival skill on day one.
• Off-by-one in range: range(10) is 0-9, not 1-10. Have students print list(range(10)) to internalize.
• Loop control (break, continue) is intuitive in lecture but rarely needed in Lab 2. Most students do not use it; that is fine.

Week 3: Functions, scope, docstrings

Pacing: function definition is fast; scope is slow. Students struggle with "the variable inside the function is not the variable outside the function." Use the id() function and the globals() / locals() dictionaries to make scope concrete.

Common blocks:

• Returning vs printing: students write print(result) inside the function and then call result = my_func(x) expecting result to hold the printed value. It holds None. Distinguish: print displays; return hands a value back to the caller.
• Default mutable arguments (def f(x=[])) are a famous Python gotcha; introduce in lecture as a warning, not a deep dive.
• Docstrings vs comments: docstrings are part of the function (accessible via help(my_func) and my_func.__doc__); comments are not. Teach this with the help() REPL session.

What to watch: Lab 3 asks students to refactor Lab 2 into named functions. Students who refactored without changing the program's behavior (no new bugs introduced) understand functions; students whose refactored Lab 2 behaves differently from the original need pair-debugging.

Week 4: Lists and dictionaries

Pacing: lists are quick (students have list-like intuition from other contexts). Dictionaries take longer because the key / value distinction is genuinely new. Add tuples and sets as a single lecture appendix.

Common blocks:

• Mutability surprises: a = [1, 2]; b = a; b.append(3); print(a) prints [1, 2, 3]. Students expect a to be unchanged. Use id(a) and id(b) to show they are the same list.
• dict.get(key) vs dict[key]: the bracket form raises KeyError if the key is missing; .get returns None. Both are correct in different contexts; teach when to use which.
• List comprehensions are introduced as syntactic sugar for a for loop that builds a list. Do NOT introduce nested comprehensions in week 4; they are week 6 material at the earliest.

Week 5: File I/O

Pacing: straightforward. The with open(...) as f: idiom is the only non-obvious syntax. CSV and JSON are stdlib one-liners and take 15 minutes each in lecture.

Common blocks:

• Text-mode vs binary-mode reads. Students who open a binary file in text mode get a UnicodeDecodeError and panic. Demonstrate the error in lecture so they recognize it later.
• Newline handling: \n on Unix, \r\n on Windows. The csv module handles this if you open with newline=''. Teach the empty-newline argument explicitly.
• "Where is my file?"; students who run open('data.txt') and get a FileNotFoundError because they were in a different directory. Teach pathlib.Path.cwd() and os.path.abspath('data.txt') as the diagnostic.

Week 6: Modules and standard library

Pacing: this is the first week where the lab (Lab 6) is a refactor, not a build. Some students find the refactor harder than a build because they have to read their own week-5 code and understand it. Budget extra office hours.

Common blocks:

• argparse is the biggest single chunk of new syntax in the course. Walk through one full example end-to-end (parser = argparse.ArgumentParser(), add_argument, args = parser.parse_args(), args.foo) before the lab.
• logging levels: students set everything to DEBUG and drown in output. Teach the level hierarchy (DEBUG < INFO < WARNING < ERROR < CRITICAL) and the convention "INFO is the default for production; DEBUG is for the developer."
• Module imports vs from-imports: import os then os.path.join(...) vs from os.path import join then join(...). Both work; the first is preferred for stdlib modules.

What to watch: Lab 6's --help output is the first place students experience CLI tool UX. A --help that reads like a sentence ("Scan a log file for ERROR lines and report counts.") is correct; a --help that reads like field names ("input output verbose") needs revision.

Week 7: Regular expressions

Pacing: regex teaching is high-variance. Some students get it in 20 minutes; others struggle the whole week. The course's discipline is "when to use regex, when NOT to"; push students toward str.split() and in for simple cases, and reserve regex for genuine pattern-matching.

Common blocks:

• Greedy vs non-greedy quantifiers (.* vs .*?). Students rarely encounter this in week 7's IP-extraction lab; mention as a forward-pointer for week-9 log analysis.
• Raw strings: r'\d+' not '\d+'. The escape rules in regular strings cause bugs that look like correct regex but match nothing. Always use r'...' for regex patterns.
• "Why didn't my regex match?" The single most useful debugger is re.findall(pattern, text) printed out. Teach it as the first move when a regex is wrong.

Week 8: Midterm

Pacing: the midterm is a 2-hour proctored practical. Students get a spec for a small argparse CLI tool (one they have not seen before) and must build it from scratch using only the Python standard library and their notes. No internet for the exam itself; the spec is precise enough that they should not need to look anything up.

Sample midterm specs (rotate):

• Build a CLI tool wordcount.py FILE that prints the word count, line count, and most-common-word for a passed file. Argparse must support --top N (default 1) to print the top-N most common words.
• Build a CLI tool csv-summary.py FILE COLUMN that reads a CSV and prints the count, min, max, and mean of the numeric values in the named column. Errors if the column is non-numeric.
• Build a CLI tool dedupe.py FILE that reads a text file and prints unique lines in order of first appearance. Support --ignore-case.

Grading: correctness 60%, argparse hygiene 20%, error handling 20%. A student who passes the exam can ship Lab 6 unaided.

Week 9: Subprocess and pdb

Pacing: subprocess is conceptually simple but full of subtle traps (quoting, shell injection, exit codes). Spend lecture time on subprocess.run with capture_output=True and text=True as the safe default.

Common blocks:

• shell=True is convenient and dangerous. Demonstrate a shell-injection vulnerability in lecture; students who understand WHY shell=True is bad will avoid it.
• Exit codes: result.returncode == 0 means success; nonzero means failure. Students who only check result.stdout miss failures.
• pdb: the four commands students need are n (next), s (step), c (continue), p variable (print). Anything else is forward-stretch.

What to watch: Lab 9's debugging exercise is the first time some students use pdb. Pair-debug in the lab session; the muscle-memory for "set a breakpoint, run, inspect, step" takes a few rounds.

Week 10: Git intermediate

Pacing: the workflow (branch, commit, push, pull-request, merge) is more important than any specific command. Students who completed FND-101's week 10 already have git init, git add, git commit, git push; FND-102 adds branches and the PR concept.

Common blocks:

• Branch naming: students create branches named temp, test, try. Teach the convention student-name/lab-N-feature early; PR-style review depends on readable branch names.
• "Where is my work?"; students who commit on main, then check out a feature branch, do not see their commit. Teach git log --all --oneline --graph as the diagnostic.
• Merge conflicts terrify students; resolve one together in lecture so the first one they hit in Lab 10 is familiar.

Week 11: Hashing and integrity

Pacing: SHA-256 as a black box is fine for FND-102. The CSA-101 + SEC-101 progression deepens the cryptographic theory; here, the practitioner discipline ("hash the file before and after, compare digests") is the lesson.

Common blocks:

• "Should I read the whole file into memory?"; for SHA-256, yes for files under ~100 MB, no for larger. Teach the chunked-read pattern (while chunk := f.read(65536): hasher.update(chunk)).
• Hex digest vs byte digest: hasher.hexdigest() returns a string; hasher.digest() returns bytes. Use the hex form for human display.

Week 12: HTTP and requests

Pacing: requests is the friendliest API in the standard ecosystem; students pick it up quickly. The harder lesson is API discipline: rate limits, error handling, JSON parsing.

Common blocks:

• API keys leaked into Git: a real risk. Lab 12 uses a no-key free weather API for that reason. Teach .env files + .gitignore as the discipline even when the lab does not require it.
• response.json() raises if the body is not JSON. Teach try / except around it.
• Rate-limiting (429 responses): mention in lecture, not in lab. Students who care will look it up.

Week 13: Testing and READMEs

Pacing: pytest's "name a function test_* and assert" model is beginner-friendly. The conceptual leap is "what is worth testing?"; the answer for FND-102 is "the happy path + the most obvious edge case + one regression test for a bug you found."

Common blocks:

• Students write tests AFTER the code is "done" and discover that the code is hard to test. Teach the test-first pattern in lecture; do not require it in lab.
• pytest discovery: tests must be in files named test_*.py or *_test.py, and functions must be test_*. The discovery rules are pickier than students expect; show pytest --collect-only as the diagnostic.
• READMEs: students conflate a README with a tutorial. The README answers three questions: what does this do, how do I install it, how do I run it. Three sections, ~150 words total, is the right length for an FND-102 tool.

Week 14: Capstone workshop

Pacing: mostly 1-on-1 scope-check meetings. Each student presents their proposed capstone in a 10-minute conversation: what is the real task, what would the tool do, what does "done" look like. The instructor's job is to push back on scope: most first-draft capstones are too ambitious. "Trim it" is the most common feedback.

Common blocks:

• "I don't have a real task to automate." Push: laundry chore rotation, sports stats scraping, weekly grocery-list generator from your meal plan, photo renaming, RSS feed digest. There is no shortage of real tasks; the student just has not noticed which ones repeat.
• "I want to use machine learning." Out of scope for FND-102. Redirect to AI-101.
• "I want to scrape this commercial website." Check the site's terms of service first; some forbid scraping. Redirect to a free API (weather, GitHub, public data) if needed.

Grading framework

The course uses three rubrics, weighted differently across labs and capstone:

Lab grading (1-7 + 9-13):

• Correctness (60%): the tool does what the spec says
• Argparse / CLI hygiene (20%): --help reads like documentation; error messages are user-friendly
• Git history (20%): more than one commit; commit messages are sentences not "fix"

Midterm (week 8):

• Correctness (60%)
• Argparse hygiene (20%)
• Error handling (20%)

Capstone:

• Code quality + craft (40%): well-named functions with docstrings; the code reads like prose; no dead code
• Tests + docs (30%): pytest tests cover the tool's behavior; README answers what / install / run
• Reflective depth (30%): the demo includes one paragraph on the bug the student found and fixed, and one paragraph on what they would do differently next time

The capstone rubric weights reflective depth heavily because the academy is teaching practitioners, not coders. A capstone that ships clean code but cannot describe its own failure modes is incomplete.

Forward-pointer cross-references

When teaching, note these connections to downstream academy courses:

• Week 3 functions -> CSA-101 Ch 6 assembler is one big Python module; the function-decomposition discipline shows up there
• Week 5 file I/O -> SEC-101 forensic analysis assumes you can read CSV / JSON dumps from log aggregators
• Week 6 argparse -> PEN-101's offensive scripts are all argparse-based; the convention transfers exactly
• Week 7 regex -> NET-101 log analysis returns to regex for IP / URL extraction
• Week 9 subprocess -> HW-101 MCU-flashing wraps avrdude / esptool via subprocess; same pattern
• Week 9 pdb -> CSA-101 Ch 9 (compiler frontend) promotes pdb to mandatory because parser recursion makes print-debugging untenable
• Week 11 hashlib -> SEC-101's integrity-monitoring labs use this; ADV-101's malware-analysis labs use it for sample identification
• Week 12 requests -> NET-101's API-scraping labs use it; AI-101's LLM-API work uses it
• Week 13 pytest -> Every academy toolchain ships with pytest tests; the discipline is universal

What to do if a student is stuck

The course's hardest weeks for non-prior-coders are 3 (functions), 4 (dict mutability), and 9 (debugging). Three rescue tactics:

1. Pair-debug. Sit next to the student and narrate what you would type next. Resist the urge to type yourself; the student's hands stay on the keyboard.
2. REPL it. Open python3 and have the student paste in just the failing line. The interactive shell collapses the feedback loop to seconds; whatever was broken in the script is usually obvious in the REPL.
3. Print everything. Before reaching for pdb, add print statements above and below the failing line: print('about to call func', args) and print('result was', result). The print-debugging discipline is correct most of the time; teach pdb for the cases where it is not.

A student who reaches week 6 cannot articulate the function / scope / mutability model needs week-3 review, not week-6 catch-up. Send them back to Lab 3, not forward.

Pilot-cohort notes (to be appended after first run)

Empty in v0.1; populate after the first cohort completes the course.

Instructor guide v0.1.