All appendices
Appendix C

Glossary

Coding 2 terms — TDD, refactoring, prompt engineering

Appendix C — Glossary

Look it up. Then go back to the reps.

This glossary is a fast reference, not a study guide. Each entry gets one to three sentences and a chapter pointer. If a term confuses you here, the chapter is where you actually learn it. Where a term is time-sensitive (a tool’s behavior, a default, a version), the entry says “as of 2026” — treat those as snapshots, not laws.

The glossary has two parts:

  1. Alphabetical — terms in A–Z order, technical and theological mixed together. Use this when you remember the word but not where it lives.
  2. By Chapter — terms grouped by the chapter that introduces them. Use this when you remember roughly when a concept showed up but not its name.

Part 1 — Alphabetical

Arrange / Act / Assert — The three-section shape of a well-written test: set up the inputs and objects (arrange), call the method under test (act), verify the result (assert). Often separated by blank lines so the structure is visible at a glance. The BDD-style synonym is Given / When / Then. (Ch 4)

assertion (JUnit) — A static check that a test’s actual result matches what’s expected. The vocabulary: assertEquals(expected, actual) (expected first, always; uses .equals() for objects, a tolerance argument for floats), assertTrue/assertFalse, assertNull/assertNotNull, assertArrayEquals, assertAll, and assertThrows(type, () -> ...) — which verifies a thrown exception and returns it for inspection, the test for your @throws claims. (Ch 4)

agentic AI — Loosely, an AI assistant that doesn’t just answer one prompt but works across multiple steps — reading code, proposing changes, iterating. This course treats the AI as a “fast junior” you direct, review, and remain accountable for; the agentic-ness is a tool, not an author. (Ch 9, Ch 13)

architecture — The decision about what shape the software has, and why: which classes exist, what each does and doesn’t do, how they talk, where state lives, and where the seams are. It is the senior engineer’s most non-negotiable contribution and the thing AI fundamentally cannot do for you, because it is judgment, not pattern-matching. (Ch 12)

architecture-first — The discipline of deciding the system’s shape — on paper, in a design doc — before a single prompt for code is written. The order is spec, architect, test — then prompt; skip the up-front design and the AI’s pattern-matching makes decisions that should have been yours. (Ch 12)

atomic write — The “write-then-rename” pattern for never corrupting an important file: write the new data to a temporary file in the same directory, then atomically rename it over the original with Files.move(tmp, target, REPLACE_EXISTING, ATOMIC_MOVE). There is no moment when the file is half-written — either the old version is there or the new one is. (Ch 6)

Babel vs Jerusalem — The chapter-12 apologetic frame. The tower of Babel (Genesis 11) is technically competent and existentially confused — built to “make a name for ourselves.” The new Jerusalem (Revelation 21) is built well and for the right end. Architecture is not neutral: the shape of a system carries values, and the “ship it fast, take the credit” posture is Babel-shaped. (Ch 12)

base case — In a recursive function, the smallest version of the problem, solved directly without recursing. Write it first: forget it (or fail to shrink toward it) and the function recurses forever, producing StackOverflowError. (Ch 7)

@BeforeEach — The JUnit 5 annotation marking a method that runs before each test, used to give every test a fresh starting state. It is how you keep tests independent — a test that depends on a previous test having run is a fragile test. (@AfterEach, @BeforeAll, @AfterAll exist for less common setup/teardown.) (Ch 4)

bisection — Debugging by binary search: cut the search space in half, decide which half holds the bug, repeat. Flavors include bisecting by code (probe the midpoint), by input (shrink toward a minimal failing case), by component (which module’s output first goes wrong), and by history (git bisect, a Coding 3 topic). (Ch 5)

bounded generic — A generic type parameter constrained to a supertype, written <T extends Number> or <T extends Comparable<T>>. Inside the method you may call any method that bound guarantees; the compiler enforces that callers supply a matching type. (Ch 8)

checked vs unchecked exception — Java’s distinctive split. A checked exception (any Exception that isn’t a RuntimeException — IOException, SQLException) must be caught or declared with throws; the compiler forces it, because it represents an environmental failure that can happen in correct code. An unchecked exception (RuntimeException and subclasses — NullPointerException, IllegalArgumentException, IndexOutOfBoundsException, IllegalStateException) needn’t be, because by convention it signals a programmer error to fix rather than recover from. (Ch 3)

code review — The discipline — not a feeling — of reading code the same way every time, against a ten-question checklist, to catch what compiles and runs but is still wrong. In Phase 2 the code is mostly AI-generated; the checklist covers hallucinated APIs, null/empty handling, boundaries (off-by-one, edge values), spec-vs-example, the big-O sniff test (O(n²) where O(n) would do), convention drift (matching the surrounding codebase), naming/taste, cruft (code that shouldn’t exist), and the accountability check — would I sign my name to this? (Ch 11)

comprehension brief — The one-page artifact you produce after reading an unfamiliar program: what it does, the shape of each class, how data flows through main, the questions a reviewer would have, and the bugs or fragilities you spotted. The deliverable for Project 1 and the model for every code review after it. (Ch 1)

compact constructor — A record-only constructor with no parameter list — public Entry { ... } — that runs validation as part of construction, so an invalid record can never exist. The strongest place to “validate at the door.” (Ch 6, Ch 8)

ConcurrentModificationException — The runtime error you get for modifying a collection (adding or removing) while iterating over it. Fix with removeIf, with collect-then-modify, or with an explicit iterator.remove(). (Ch 5, Ch 8)

context window — The slice of code and information you paste into a prompt. The rule of thumb: include exactly enough that a careful human reader could answer the question — less and the AI guesses, more and it gets distracted and “helpfully” changes things you didn’t ask about. (Ch 10)

contract — A specification with both sides bound: the caller agrees to satisfy the preconditions, the method agrees to deliver the postconditions. If the caller breaks their half, the method’s behavior is undefined and that’s the caller’s bug; if the method breaks its half while the caller held up theirs, the method has a bug. (Ch 2)

convention drift — When AI-generated code is written the way a generic Java author would write it rather than the way your file would — wrong indentation, System.out instead of your logger, T-or-null instead of your Optional. Caught in the consistency review; prevented by pasting a style reference into the prompt. (Ch 11)

correction loop — The expensive failure mode of AI-assisted debugging: the AI fixes test A and breaks test B, you re-prompt, it fixes B and breaks A, and the test set oscillates forever. The signal is “same shape of fix, oscillating failures.” Break it by stating both constraints in one prompt and asking the AI to name the joint invariant first. (Ch 13)

covenant — A binding promise — in the biblical sense, usually initiated by God — with terms specified precisely enough that a much-later reader can still tell who is keeping faith with it. The chapter-2 frame for specifications: a method’s Javadoc is a covenant in software form. The Augsburg Confession (1530) is the worked human example. (Ch 2)

CSV — Comma-separated values: one record per line, fields separated by commas. Almost dead-simple, until a field contains a comma, a newline, or a quote. For data you didn’t author, use the careful parser (quoted fields, doubled quotes) rather than String.split(","), or reach for a library. (Ch 6)

custom exception — An exception class you write when the standard library has no type that means what you mean. Extend Exception for checked, RuntimeException for unchecked; always provide a (String message) constructor and a (String, Throwable cause) constructor; suffix the name with Exception. (Ch 3)

debugging discipline — Hypothesis-driven inquiry, not “trying things”: observe the symptom precisely, form a specific hypothesis about the cause, predict what a small probe would show, test, then confirm or revise before changing any code. The same loop, later, vets AI-generated code. (Ch 5)

diagnostic correction — Pushing back on a wrong AI answer by asking it to find its own bug — “walk through this call line by line and tell me where the value diverges” — rather than telling it the fix. Use it when you have a symptom but not yet a cause; it doesn’t bake in your wrong guess, and each round teaches you the code. Contrast directive correction. (Ch 13)

directive correction — Telling the AI exactly what the bug is and what to change. Fast and cheap when you already know the cause; a wasted round (or worse, a new bug) when you’re confident and wrong. The mature pattern is diagnostic first, directive once the cause is known. (Ch 13)

discernment — In the chapter-11 frame (1 John 4:1, “test the spirits”), the practiced, criteria-based discipline of distinguishing true from false — not a feeling. Code review is its engineering form: you test the AI’s output against the spec, the tests, and the docs, every time, because well-intentioned and right are not the same thing. (Ch 11)

equals (overriding) — The Object.equals(Object) method that compares contents; override it (with hashCode) when a class’s instances should be value-comparable. == on objects compares references, not contents — a recurring AI and student bug. Records generate a sensible equals for you. (Ch 6, Ch 8)

epistemology — The branch of philosophy asking how knowledge is possible. The chapter-4 frame: testing is the correct response to a claim — “test everything; hold fast what is good” (1 Thess 5:21). A spec is a claim; a test examines it; a passing test is verification. (Ch 4)

examen — The Christian discipline of an honest, disciplined review of the day — where did I go wrong, and why? The chapter-5 cousin of debugging and of the rubber duck: both crafts invented the same kind of out-loud self-review because we are not naturally good at seeing our own errors. (Ch 5)

exception — A Java object representing an abnormal condition. Code throws it; it travels up the call stack until something catches it; uncaught, it prints a stack trace and exits. Every exception is a subclass of Throwable. (Ch 3)

exception chaining — Preserving the original exception as the cause when you catch one and throw another: throw new CatechismLoadException("...", e). A catch that throws without passing the cause destroys the diagnostic evidence (the “Caused by:” line). Always chain when you wrap. (Ch 3)

fail fast — Detect a problem at the earliest point you have enough information, and throw immediately with a useful message, rather than letting a corrupt value travel deeper. The right policy for precondition and invariant violations inside the program. Paired with graceful degradation at the edges. (Ch 3)

try / catch / finally — The basic exception-handling structure: code that might throw goes in try, the handler in catch, and cleanup that must run regardless (normal return, caught, or uncaught) goes in finally. An empty catch body silently swallows every error and is one of the worst things you can write in Java — at minimum, log it. (Ch 3)

try-with-resources — The preferred way to handle anything closeable: declare it in the try (...) header and Java guarantees close() runs when the block exits, exception or not — cleaner than finally { x.close(); } and impossible to forget. Works for any AutoCloseable (most readers, writers, scanners, connections); Java’s answer to C++ RAII. (Ch 3, Ch 6)

Files (java.nio.file.Files) — The modern Java file API. As of Java 11, Files.readString, Files.writeString, Files.readAllLines, and Files.write cover almost every file task in this book; Files.walk recursively yields every path under a root. Defaults to UTF-8 on Java 17. (Ch 6, Ch 7)

generic type parameter — The <T> (or <String>) that tells the compiler what a class or method is parameterized over. ArrayList<String> holds only Strings; the compiler enforces it at compile time and inserts the casts for you. Roughly Java’s answer to C++ templates, but erased at runtime. (Ch 8)

graceful degradation — When something goes wrong but a sensible fallback exists, recover and continue — ask the user again, use a default, retry, fall back to cached data. The right policy at the edges of the program (user input, file I/O, network), where failure is normal. (Ch 3)

hallucinated API — A method, class, or library the AI confidently uses that does not exist — String.splitCsv(), Files.readJson(), Optional.getOrElse(). The most common AI failure and the easiest to catch: Java 17’s standard library is closed and documented (as of 2026), so if it’s not in the docs (or won’t compile), it isn’t real. Treat any unfamiliar method name as guilty until proven innocent. (Ch 9, Ch 11)

hypothesis-driven debugging — The core habit of Chapter 5: form a hypothesis before changing a single line. A specific claim about the cause (“the loop stops one iteration early because the bound is < not <=”), a small probe to confirm it, and only then a fix — followed by a regression test. (Ch 5)

integration test — A test that exercises multiple components working together — reading a real (temp) file, running a whole input-to-output pipeline. Slower and more fragile than a unit test, but catches wiring, configuration, and contract-mismatch bugs. The midterm requires both. (Ch 4)

interface — A named contract of method signatures with no implementation, which many classes can implement and callers can depend on by the interface type. In Phase 2 the senior’s primary architectural tool: a seam where one implementation (JSON persistence) can be swapped for another (SQLite) without touching the rest of the system. (Ch 8, Ch 12)

invariant — Something that must always be true about an object, before and after every method call — balance >= 0, “events stored in insertion order.” The class’s responsibility; a method may break it momentarily inside its body but must restore it before returning. Write the invariants first and the methods almost design themselves. (Ch 2)

iterating on the prompt — When the first answer is wrong, editing the original prompt to be sharper and re-sending, rather than patching the response with “fix the X part.” A clean re-prompt usually beats a patch, because a patched answer carries the original flaw forward in a buried form. (Ch 10)

iterative refinement — The Phase-2 skill of driving the AI to correct, working code through a hypothesis-driven loop: symptom → hypothesis → targeted prompt → re-run tests. The same debugging discipline as Chapter 5, with the prompt as the scalpel and the test suite as the contract. (Ch 13)

Javadoc — Java’s standard mechanism for documentation embedded in source as a /** ... */ block immediately before a class, method, or field. The compiler ignores it; the javadoc tool renders it to HTML. The tags you’ll use: @param, @return, @throws, @see, {@code ...}, {@link ...}. The first sentence is treated as the summary, so make it a real one. (Ch 1, Ch 2)

JUnit 5 — The standard Java testing framework (also called JUnit Jupiter), not part of the JDK — the infrastructure that finds every @Test-annotated method, runs them all, and reports pass/fail with diagnostic messages, sparing you from hand-rolling if (result != expected) print("FAIL"). In OnlineGDB it’s preinstalled (as of 2026), so there’s nothing to install and no admin rights needed; the setup workflow is in Appendix B. (Ch 4)

java.time — The modern Java date-and-time package. Instant is a moment in time (used for event timestamps); LocalDate is a calendar date (used for habit check-ins and streaks). Preferred over the older java.util.Date. (Ch 9, Ch 12)

java.util.logging (JUL) — The JDK’s built-in logging API, fine for this course with no extra dependencies. Idiom: one private static final Logger LOG = Logger.getLogger(ClassName.class.getName()) per class; log the exception and its stack trace, not just the message; pick the right level (INFO, WARNING, SEVERE). (Ch 3)

logging — Keeping a deliberate record of what happened — especially of errors you handled gracefully — so the underlying problem can be found and fixed later. The other half of robust code alongside exception handling; an empty catch that logs nothing is a hiding strategy, not a recovery strategy. (Ch 3)

Luhn algorithm — The checksum every credit card number satisfies: from the right, double every second digit (subtract 9 if ≥ 10), sum all digits, and the number is valid iff the sum is divisible by 10. Used in Chapter 10 as the worked “vague prompt vs precise prompt” example. (Ch 10)

List / Map / Set — The three java.util collection interfaces you’ll use forever: List is an ordered sequence allowing duplicates (default ArrayList; LinkedList for the rare deque case), Map is key-to-value lookup (“I have a name and want the thing it names”), Set is distinct membership (“have I seen this?”). The rule: program against the interface, instantiate the implementation — List<String> x = new ArrayList<>(). (Ch 7, Ch 8)

collection implementations — The hash/linked/tree families behind Map and Set. HashMap/HashSet are fast (O(1) average) but iteration order undefined — don’t depend on it; LinkedHashMap/LinkedHashSet add insertion-order iteration; TreeMap/TreeSet iterate in sorted key order at O(log n). Default to the hash version; pay for order only when you need it. getOrDefault(k, 0) and removeIf(...) are the boilerplate-savers worth memorizing. (Ch 8)

memoization — Caching a recursive call’s result so the second request for the same input returns the cached answer instead of recomputing. Turns naïve Fibonacci from exponential to linear with two extra lines. The seed of dynamic programming in Coding 3. (Ch 7)

minimal failing case — The smallest input that still triggers a bug, reached by shrinking a known-failing input (bisecting by input). Usually small enough to read by hand, which is the point. (Ch 5)

negative constraint — A prompt instruction about what the AI must not do — “no helper methods,” “don’t catch exceptions,” “java.util and java.lang only,” “don’t refactor the code I’m pasting.” At least as powerful as positive instructions for tightening output; the prompt-engineering echo of the confessions’ “and we reject…” (Ch 10)

Objects.requireNonNull — The one-line fail-fast null check: Objects.requireNonNull(name, "name") throws NullPointerException("name") if name is null. Use it at the top of every method whose spec says “must not be null” — it turns a mysterious later NPE into a clean, labeled one immediately. (Ch 2, Ch 3)

off-by-one error — A loop bound or index that is one too high or one too low (< where <= belongs, size() - n - 1 where size() - n belongs). Predates AI by fifty years; AI inherits them from its training data. Caught by reading the bound twice and by a boundary test. (Ch 5, Ch 11)

OnlineGDB — The browser-based IDE this course continues to use for Java, with JUnit 5 preinstalled — no local install, free account, no admin rights required. The setup details live in Appendix B. (Ch 4, Appendix B)

plausible but wrong — AI code that compiles, runs, reads like it’s doing the right thing, and is silently wrong on inputs the AI didn’t consider — integer division in an average, the median of an even-length array, a method that mutates the caller’s argument. The most insidious failure: “works on the example” is necessary, not sufficient. (Ch 9, Ch 11)

postcondition — What the method guarantees to be true after it returns, given the caller satisfied the preconditions — “returns the smallest matching index, or -1,” “size increased by exactly one,” “the returned list is unmodifiable.” A promise the caller can rely on without reading the body. (Ch 2)

precondition — What must be true before a method is called for it to do its job — “arr must not be null,” “0 <= index < size().” The caller’s responsibility; violate it and behavior is undefined (well-written Java converts that into a specific exception via fail-fast). (Ch 2)

println debugging — Probing a program by printing values at chosen points (prefix each with a tag like DEBUG so you can grep them out). Trivial, works everywhere, and the primary debugging tool for this course; senior engineers use it daily and never apologize for it. The point is the hypothesis, not the tool. (Ch 5)

prompt — The specification the AI actually reads. Not “like” a spec — it is one, with the twist that the AI won’t ask a clarifying question; it picks a reading of any ambiguity and ships code on it. A sharp prompt has four parts: role/context, signature, behavior (with examples), and constraints. (Ch 10)

prompt template — A reusable prompt shape worth memorizing — implement-to-signature, test-first, refactor, explain, find-the-bug (Ch 10), plus the diagnostic templates of Chapter 13 (trace-don’t-fix, minimal-targeted-fix, both-constraints, restate-the-spec). Save the ones that work into your own prompt-toolbox. (Ch 10, Ch 13)

prompt-as-spec — The chapter-10 thesis that precision in prompting is the same skill as precision in spec-writing, and the highest-leverage skill in Phase 2. Five well-placed words can save two hours of reviewing wrong code; the prompt and the spec are the same artifact, aimed at a different reader. (Ch 2, Ch 10)

prompts.txt — The chronological log of every prompt you send the AI, a required deliverable on every Phase 2 project; the grader reads it alongside your code. Log in real time, log everything (especially the small stuff), and never trim or falsify it — a falsified log is treated as an academic-integrity violation. (Ch 9, Ch 14)

record — Java 14+‘s declaration for a simple, immutable value-bearing class: record Entry(int number, String question, String answer) {} gives you final fields, a constructor, accessors, and sensible equals/hashCode/toString. The right shape for a parsed CSV row or JSON object; use it aggressively. (Ch 6)

red-green-refactor — The TDD cycle. Red: write a failing test for the next small behavior. Green: write the simplest code that makes it pass. Refactor: clean up with the tests still passing, running them after every change. Then repeat. (Ch 4)

regression test — A test that fails before a fix and passes after, locking the fix in place so the same bug can’t sneak back in a later refactor. The course rule: every bug fix ships with a test, ideally commented with the bug it guards against. (Ch 5)

recursion — A function defined in terms of a smaller version of itself, with a base case that stops it and a recursive case that shrinks toward the base. The right tool when the data is recursive — directory trees, nested maps, expressions; the wrong reflex for flat, loop-shaped problems. (Ch 7)

refactoring — Changing the structure of code without changing its behavior — better names, extracted helpers, removed duplication. Safe only with tests: refactoring without tests is “changing the code and hoping.” The third beat of red-green-refactor and the proof that a real spec is implementation-independent. (Ch 1, Ch 2, Ch 4)

reading code — The senior engineer’s primary skill: not “my eyes passed over it” but answering what the program does, its shape, where data flows, its hidden assumptions, what would break it, and what a reviewer would ask. Trained on humans’ code in Phase 1 so it can audit the machine’s code in Phase 2. (Ch 1)

secondary causes — The doctrine that God often acts through something else (rain waters the crop; the carpenter builds the table) without diminishing the reality of either cause. The chapter-9 frame for AI authorship: the AI is a tool you wield; your spec, judgment, review, and accountability make the work genuinely yours. (Ch 9)

seam — A point in a system — usually an interface — where one implementation can be swapped for another without touching the rest. Introduce a seam where you predict the implementation might change (persistence, an external clock, a strategy), and only there; premature seams are clutter. (Ch 12)

senior/junior model — The mental model the whole of Phase 2 runs on. You are the senior — you spec, architect, review, test, and stay accountable; the AI is the junior — fast, willing, voluminous, and confidently wrong perhaps fifteen percent of the time with no inner sense of when. In a senior’s hands AI makes good code faster; in anyone else’s it makes bad code faster. (Ch 9)

signature-first prompting — The single most effective prompt habit: hand the AI the exact method signature (with Javadoc), not a prose description of it. The signature has already made every decision — return type, parameter type, static-or-instance, throw-or-return — that a prose prompt leaves to chance. (Ch 10)

single responsibility — The principle that a class does one thing. The plain test: if you need the word “and” to describe it (“loads habits and saves them and formats them”), split it; the new boundary is usually obvious once you see the “and.” Names like Manager, Util, Helper, Service are smells for “I haven’t decided what this is.” (Ch 12)

slow read vs fast read — Two reading modes for AI output. The fast read (30 seconds) asks “is this the kind of answer I expected, and does it compile?” The slow read (5–10 minutes, with the ten-question checklist) asks “does every method exist, are nulls and boundaries right, does the spec match the code?” Most students stop after the fast read; the bugs live in the slow one. (Ch 11)

specification (spec) — A written promise about behavior. For a method it answers four questions: what it does (purpose), what must be true before (preconditions), what’s guaranteed after (postconditions), and what stays true throughout (invariants). Written before the code, it disciplines the thinking and becomes what you check the implementation — or the AI — against. (Ch 2)

specification-driven design — Writing the contract first — signatures, constraints, guarantees — and the method body last, because once the contract is firm the body almost writes itself. The single largest skill gap between junior and senior, and the foundation of good prompting. (Ch 2, Ch 10)

specifying by example — Pinning down behavior with concrete input → output pairs rather than prose, because where a sentence is ambiguous an example is not. Each example is worth a paragraph; a real example from your codebase is worth more than a hypothetical one. (Ch 10)

stack frame — The chunk of stack memory holding one method call’s locals, parameters, and return address. Frames stack on top of each other; a recursive function’s stack depth equals its recursion depth, and a too-deep recursion exhausts the stack. (Ch 7)

stack trace — The list of stack frames printed when an uncaught exception fires, deepest call first. Read all of it: the thread name, the exception class (the category), the diagnostic message (Java 17’s “helpful NullPointerExceptions” name the null variable), and the frames — the top is where it manifested, lower frames may be where the bug lives. (Ch 5)

StackOverflowError — The error from infinite (or merely too-deep) recursion — a missing base case or a recursive call that doesn’t shrink. The ... N more ellipsis in its trace is Java’s way of truncating a miles-long stack. (Ch 5, Ch 7)

structural recursion — Recursion whose shape mirrors recursively-defined data: each piece is either a leaf (handle it) or a node (recurse into it) — walking a nested Map, walking a directory tree. The universal shape you’ll meet again as tree traversal in Coding 3. (Ch 7)

taste — The senior’s irreplaceable judgment that good code “works and is still ugly”: this method shouldn’t exist, that name says nothing, a Set would beat this Map. An LLM can pattern-match taste convincingly but cannot generate it from first principles, because it lives in the experience of having shipped, broken, and re-read code for years. (Ch 9, Ch 11, Ch 12)

TDD (test-driven development) — Writing the test before the code it tests, watching it fail, then writing the smallest code that makes it pass. The watching-it-fail step matters: a test that passes against an empty implementation isn’t testing anything. The muscle that makes a Phase-2 engineer trustworthy. (Ch 4)

test as spec — The principle that a failing test is the most unambiguous specification available: for this input, expect this output, in this exact form, pass or fail, no room to misunderstand. In Phase 2 the test suite is your contract with the AI, and the progress signal is “failing tests went down and stayed down.” (Ch 10, Ch 13)

test-first prompt — Handing the AI a failing JUnit test and asking for code that makes it pass. The most effective prompt format: it removes interpretation by giving the contract in machine-readable form. (Ch 10)

testing as discipline — The conviction that tests are how you trust code, not merely how you prove it. You verify because a claim deserves checking; in Phase 2 the claim is often the AI’s, and the test suite is what stands between you and shipping confident garbage. (Ch 4)

theodicy — The theology of why the world breaks and what to do about it — the chapter-3 frame, carried forward from Coding 1. Romans 8:28 doesn’t say nothing goes wrong; it says brokenness is not the final word. Robust software is the small-scale discipline of expecting failure and responding deliberately. (Ch 3)

throw / throws — throw raises an exception (throw new IllegalArgumentException("...")) — use the most specific type, include the offending value in the message, and throw early (fail fast). throws on a method signature declares the checked exceptions it may propagate (throws IOException), part of the contract that forces callers to catch or re-declare them. (Ch 3)

typed boundary — A module interface that passes typed values (a record Habit(...)) rather than untyped ones (Map<String, Object>), so a change on one side doesn’t ripple to the other. The pattern: parse at the edges, type in the middle, render at the edges. (Ch 12)

unit test — A test of one small piece of code — usually one method on one class — in isolation, running in microseconds, touching no disk, network, or database. Most of the tests you write. Contrast integration test. (Ch 4)

var — Java 10+‘s local-variable type inference: var list = new ArrayList<String>(). Local variables only — it can’t be a field, parameter, or return type. A common spot for AI to misuse it in Java 17. (Ch 7, Ch 11)

validation — Checking that data from outside your program is trustworthy before you act on it — “trust nothing the file says.” Three layers: in the constructor (a record’s compact constructor — strongest), in the parser, and in a separate collect-all-errors pass. (Ch 6)

vibe coding — The internet’s name for producing code you can’t tell is correct, fast, safe, or even solving the right problem — partnership-first without the sharpening, or letting the AI make the architectural and review decisions that are the senior’s job. The exact failure mode this whole course is built to prevent. (Ch 9, Ch 12)

vocation — The Lutheran conviction that one’s honest work is a calling in service of one’s neighbor — and that the calling isn’t invalidated when the tools improve. The diagnostic question for AI use: after a project with AI, do you understand more or less than you would have without it? More means you used it well. (Ch 9, Ch 14)

Part 2 — By Chapter

Terms in roughly the order they’re introduced. Definitions live in Part 1.

Chapter 1 — Reading Code Like Scripture

  • reading code
  • comprehension brief
  • Javadoc (reading the standard library’s)
  • refactoring (behavior-preserving, P1 Hard tier)

Chapter 2 — Contracts and Specifications

  • specification (spec)
  • contract
  • precondition
  • postcondition
  • invariant
  • Javadoc (writing it)
  • specification-driven design
  • covenant
  • Objects.requireNonNull (foreshadowed)

Chapter 3 — Exception Handling

  • exception
  • try / catch / finally
  • try-with-resources
  • throw / throws
  • checked vs unchecked exception
  • custom exception
  • exception chaining
  • fail fast
  • graceful degradation
  • logging
  • java.util.logging (JUL)
  • Objects.requireNonNull
  • theodicy

Chapter 4 — Testing as Discipline

  • testing as discipline
  • JUnit 5
  • @BeforeEach
  • assertion (JUnit)
  • Arrange / Act / Assert
  • TDD (test-driven development)
  • red-green-refactor
  • unit test
  • integration test
  • epistemology

Chapter 5 — Debugging Discipline

  • debugging discipline
  • hypothesis-driven debugging
  • stack trace
  • StackOverflowError
  • ConcurrentModificationException
  • bisection
  • minimal failing case
  • println debugging
  • regression test
  • off-by-one error
  • examen

Chapter 6 — Files, Data, and Persistence

  • Files (java.nio.file.Files)
  • CSV
  • record
  • compact constructor
  • validation
  • atomic write
  • try-with-resources (revisited)

Chapter 7 — Recursion

  • recursion
  • base case
  • structural recursion
  • stack frame
  • memoization
  • var

Chapter 8 — Collections, Generics, and Midterm Review

  • List / Map / Set
  • collection implementations
  • generic type parameter
  • bounded generic
  • equals (overriding)

Chapter 9 — Pair Programming With AI

  • senior/junior model
  • agentic AI
  • taste
  • hallucinated API
  • plausible but wrong
  • java.time
  • secondary causes
  • prompts.txt
  • vibe coding
  • vocation

Chapter 10 — Prompts as Specifications

  • prompt
  • prompt-as-spec
  • signature-first prompting
  • specifying by example
  • negative constraint
  • test-first prompt
  • test as spec
  • context window
  • iterating on the prompt
  • prompt template
  • Luhn algorithm

Chapter 11 — Code Review

  • code review
  • discernment
  • slow read vs fast read
  • convention drift

Chapter 12 — Architecture First

  • architecture
  • architecture-first
  • single responsibility
  • interface
  • seam
  • typed boundary
  • Babel vs Jerusalem

Chapter 13 — Iterative Refinement

  • iterative refinement
  • diagnostic correction
  • directive correction
  • correction loop
  • prompt template (diagnostic)

Chapter 14 — The Honesty Question

  • vocation (revisited)
  • prompts.txt (the honesty standard)
  • secondary causes (authorship)

Chapter 15 — Capstone Preparation

  • (no new terms — Phase 2 skills consolidated)

Chapter 16 — Final Review and Exam

  • (no new terms — the whole course cashed in)

Coach’s Note — Don’t read this appendix straight through. Open it when a word slips your mind, find the entry, click the chapter pointer, and re-read the section that introduces the term in context. In Phase 1 the glossary is the index card and the chapter is the gym. In Phase 2 it’s also a review checklist — run your eyes down the Chapter 11 entries before you sign off on a piece of AI’s code. The term is the reminder; the discipline is the work.