Chapter 16 · Week 16

Final Review

What can a Christian engineer build?

Chapter 16 — Final Review

“Each one’s work will become manifest, for the Day will disclose it, because it will be revealed by fire.” — 1 Corinthians 3:13

“The end of all our exploring will be to arrive where we started and know the place for the first time.” — T. S. Eliot, Four Quartets

Why This Matters

The final is this week.

This is the last chapter of the book. By design, it adds no new technical material. Its job is to compress what you already know into a form you can carry into the exam room, and to walk you up to the door of the capstone.

If you have done the reps — every comprehension brief, every spec, every test-first suite, every sabotage recovery, every catechism pipeline, every recursive walk, every collections drill, every spec-AI-review project, every prompt comparison, every code review, every architectural sketch, every iterative-refinement loop, every honesty reflection, and every capstone drill — Project 14 is going to feel like another project. A well-paced 60-minute version of the work you have done many times.

If you have not, the final is going to be harder than you’d like. The advice is the same advice as Chapter 8 (the midterm review): there is no substitute for the reps, but there is real value in the honest assessment the exam will give you. Use it that way.

16.1 — Coding 2, Compressed

A one-paragraph reminder of each chapter. If any don’t ring a bell, re-read.

Chapter 1 — Reading Code Like Scripture. Senior engineers spend more time reading than writing. The six-question read: what does it do? what’s the shape? where does data come from and go? what are the assumptions? what would break it? what would a reviewer ask? Reading is the foundation of every Phase 2 skill.

Chapter 2 — Contracts and Specifications. A specification is a promise about behavior. Pre/postconditions, invariants, error cases, the public API. Write before you build. The spec is the contract — for you, for your reviewer, for the AI.

Chapter 3 — Exception Handling. try/catch/finally. Checked vs. unchecked. Custom exceptions when the language doesn’t have the right one. Exception chaining (new X(...).initCause(e)). The principle: every error is handled deliberately, not by accident.

Chapter 4 — Testing as Discipline. JUnit 5. Arrange / Act / Assert. Test-first development: write the test, watch it fail, write the code, watch it pass. Trust the tests, then trust the code. Tests are the foundation of trusting AI-generated code in Phase 2.

Chapter 5 — Debugging Discipline. Hypothesis-driven debugging. Symptom → hypothesis → evidence → fix → regression test. The discipline you built here is the discipline you used in Chapter 13 to diagnose AI’s wrong answers.

Chapter 6 — Files, Data, and Persistence. java.nio.file. Reading and writing text, CSV, JSON. Parsing carefully. Normalizing data. The persistence layer is where your program meets the messy real world; treat the boundary as the contract.

Chapter 7 — Recursion. Base case + recursive case. Mathematical recursion (gcd, factorial). Structural recursion (walking a directory tree, pretty-printing nested maps). Memoization. When recursion reads more clearly than iteration, prefer it; when not, don’t.

Chapter 8 — Collections, Generics, and Midterm Review. Map, Set, List from java.util. Generics: Map<String, List<Book>>. The standard library you actually use. The Apologetics Catalog midterm ties Phase 1 together.

Chapter 9 — Pair Programming With AI. The senior/junior model. What AI is good at (boilerplate, scaffolding, conventional code). What AI is bad at (architectural judgment, edge cases the spec didn’t name, novel APIs). Hallucinated APIs as the canonical failure mode.

Chapter 10 — Prompts as Specifications. Precision in prompts is precision in specs. Constraints, in-prompt examples, the test-first prompt. The vague prompt and the precise prompt produce demonstrably different output quality.

Chapter 11 — Code Review. The four classes of subtle AI wrongness: off-by-one, wrong null handling, hallucinated API, ignored edge case. Code review is the discipline that catches them. 1 John 4:1 as the framing — test the spirits.

Chapter 12 — Architecture First. The senior engineer’s non-negotiable job: decide the shape of the system before prompting for the modules. Single responsibility, interface boundaries, the swappable persistence layer. AI writes any module; AI does not decide which modules to ask for.

Chapter 13 — Iterative Refinement. What to do when the AI’s first answer is wrong. Diagnostic vs. directive prompting. Narrowing scope. Showing the test in the prompt. Breaking the correction loop. Knowing when to stop iterating and write it yourself.

Chapter 14 — The Honesty Question. Three honest statements you can always make: I wrote the spec. I directed the AI. I tested it. The architect analogy. The Eighth Commandment applied to attribution. The reflection in P14 is graded on this.

Chapter 15 — Capstone Preparation. The fourteen skills, in their integration order. The worked example. The study plan (7-day and 3-day versions). The Capstone Drills exercise file.

That is Coding 2.

16.2 — The Five Patterns of a Real Small Application

Most of the time, when you build something small but real, your code follows one of these five patterns. Recognize the pattern; the implementation follows.

Pattern 1 — Load, transform, persist

public class CsvProcessor {
    public void process(Path in, Path out) throws IOException {
        List<String> lines = Files.readAllLines(in);
        List<Record> records = lines.stream()
            .map(Record::parse)
            .filter(Record::isValid)
            .collect(Collectors.toList());
        Files.write(out, records.stream()
            .map(Record::toJson)
            .collect(Collectors.toList()));
    }
}

The shape of the Catechism Data Pipeline (P6) and any data-cleaning capstone scope (sermon-note indexer, hymn data import). Read → transform → write. Errors surface at the parsing boundary.

Pattern 2 — State machine over time

public class StudyStreakTracker {
    private final Path stateFile;
    private LocalDate lastCheckIn;
    private int currentStreak;

    public void checkIn(LocalDate today) throws IOException {
        if (lastCheckIn == null || today.equals(lastCheckIn.plusDays(1))) {
            currentStreak++;
        } else if (!today.equals(lastCheckIn)) {
            currentStreak = 1;
        }
        lastCheckIn = today;
        persist();
    }
}

State that survives across runs. Streak trackers, journals, todo lists, rotators. The persistence boundary is where the state machine meets the filesystem. Test the transition rules with JUnit; test the persistence with a round-trip integration test.

Pattern 3 — Index and query

public class SermonNoteIndexer {
    private final Map<String, Set<Integer>> wordToLines;

    public void buildIndex(List<String> lines) {
        for (int i = 0; i < lines.size(); i++) {
            for (String word : lines.get(i).toLowerCase().split("\\W+")) {
                wordToLines.computeIfAbsent(word, k -> new HashSet<>()).add(i);
            }
        }
    }

    public Set<Integer> search(String word) {
        return wordToLines.getOrDefault(word.toLowerCase(), Set.of());
    }
}

Build a map from keyword to locations. Query against the map. Apologetics Catalog (P8) was this shape. Any “indexer” capstone scope is too. The collections vocabulary from Chapter 8 lives here.

Pattern 4 — Generator with state

public class DailyVerseRotator {
    private final List<Verse> all;
    private final Set<String> shown;

    public Verse next() {
        if (shown.size() == all.size()) {
            shown.clear();
        }
        Verse picked = all.stream()
            .filter(v -> !shown.contains(v.getReference()))
            .findFirst()
            .orElseThrow();
        shown.add(picked.getReference());
        persist();
        return picked;
    }
}

Each call returns the next item from some sequence, with state tracking what has already been returned. Verse rotators, prayer prompts, hymn suggesters. Same persistence pattern as state-machine-over-time; the difference is that the public API is next() instead of explicit state transitions.

Pattern 5 — Index + ranked retrieval

public class HymnSuggester {
    private final List<Hymn> hymns;

    public List<Hymn> top3(String theme) {
        return hymns.stream()
            .sorted(Comparator.comparingInt(h -> -h.matchScore(theme)))
            .limit(3)
            .collect(Collectors.toList());
    }
}

Score each candidate; return the top N. Hymn suggester, search-result ranker, recommendation engine. The interesting work is the scoring function; the framework around it is boilerplate.

The five patterns cover essentially every legal Project 14 scope. Identify the pattern in your scope first, then spec, then code. The pattern is the architecture; the architecture is what you build.

Coach’s Note — I have given variants of this final for several semesters. Without exception, students who recognized the pattern in the first 5 minutes shipped on time. Students who tried to invent an architecture from scratch shipped late or not at all. The pattern is the shortcut. Use it.

16.3 — Bugs You’re Most Likely to Hit on the Exam

Same list as Chapter 15. Tape it next to your keyboard.

  1. == on Strings. Use .equals().
  2. NullPointerException. Some reference was null when you assumed it wasn’t.
  3. ArrayList<int>. Use Integer.
  4. Missing @Override. Silent polymorphism failure.
  5. Scanner.nextInt() then nextLine(). Flush.
  6. File not found, unhandled. throws IOException or wrap in try/catch.
  7. Hallucinated API. AI invented LocalDate.fromString(). Compile and check.
  8. AI rewrote the wrong method. Diff before accepting.
  9. Test passes, code is wrong. Test was weaker than the spec. Re-read the spec.
  10. Forgot to log a prompt. Log in real time.

Look at these between problems on the exam. They are the cheapest 10 points available.

16.4 — Study This Week

Same plan as Chapter 15’s §15.6, restated briefly.

You have 7 days, or maybe 3.

Day 1. Re-read Chapter 15 (worked example, study plan). Re-read this chapter. Re-read §16.5 (exam logistics).

Days 2–3. Do Drills 1, 2, 3 from chapters/15-capstone-prep/exercises.txt. Spec, tests, architecture. Twice each. Timed.

Days 4–5. Do Drill 5 from Chapter 15’s exercises — the full 45-minute mini-capstone. Twice, with two different scopes. The second run is more valuable than the first.

Day 6. Re-read your own prompts.txt from Projects 9–13. Build a final my-prompts.txt with your 5 best templates. Print it.

Day 7 (exam day). Re-read §16.3 (bug list). Re-read §16.2 (the five patterns). Get a real meal. Show up early. Do not learn anything new on exam day.

3-day version (you’re behind): Day 1 = Drill 5 once. Day 2 = Drill 5 again, different scope. Day 3 = light review, sleep early. It works if you do it.

16.5 — Exam Rules and Logistics

  • 60 minutes (your instructor may adjust to 75).
  • Open-textbook. This book, printed or non-interactive PDF.
  • Open-AI. The course’s default AI assistant, as you’ve used it in Phase 2.
  • Closed-internet. No browsing other than the AI interface.
  • No human help. Solo. No DMs, no calls, no friends.
  • Submit one URL — your OnlineGDB Java project link (recommended) or a public GitHub repo URL. See Project 14 for the exact submission requirements.

The exam project is P14: A Real Small Application. The full spec is in Project 14. Read it now. Read it again the night before.

16.6 — A Direct Word, One More Time

The final is open-AI by design. It is not open-AI because that makes it easier. It is open-AI because that matches the environment you will work in for the rest of your career.

The trap is the inverse of the midterm’s trap. The midterm exposed whether you had the Phase 1 skills the AI normally provides cover for. The final exposes whether you have the Phase 2 senior skills the AI cannot provide at all.

The student who does well on the open-AI final:

  • Writes a 3-minute spec.
  • Writes tests before prompting.
  • Asks the AI for one method at a time, scoped.
  • Reads every line of AI output for the Chapter 11 failure modes.
  • Logs every prompt as they go.
  • Reflects honestly at the end.

The student who does badly:

  • Skips the spec.
  • Pastes “build a daily-verse rotator” into the AI and accepts what comes back.
  • Doesn’t write tests.
  • Doesn’t review.
  • Logs prompts from memory at minute 58.
  • Submits something they cannot fully explain.

Two students. Same grade so far. The final separates them. That is the test.

If your honest answer to the question “can I stand behind what I am about to submit?” is yes — submit and rest. If it is no — change the submission until it is yes.

16.7 — What’s On the Exam (in General Shape)

The actual prompt is sealed. The shape is no secret.

Project 14 will require you to:

  • Pick one scope from the approved list. (Project 14 lists them: daily-verse rotator, study-streak tracker, sermon-note indexer, prayer-journal recorder, hymn-suggestion generator.)
  • Write a spec doc. P2 skill.
  • Write at least 6 JUnit tests before the production code. P4 skill.
  • Persist data to a file in a documented format. P6 skill.
  • Handle exceptions deliberately at the I/O boundary. P3 skill.
  • Document the module architecture in a brief architecture doc. P12 skill.
  • Use AI for at least 2 individual methods, with the prompts logged. P9, P10, P13 skills.
  • Write a reflection.docx about what the AI got right, what you redirected, what you wrote by hand. P14 honesty work.

Sound familiar? It is the integration of every Phase 2 skill into one small program. The full rubric and tier breakdowns are in Project 14.

16.8 — A Theological Footnote on the Final

The epigraph for this chapter is from 1 Corinthians 3:13 — each one’s work will become manifest, for the Day will disclose it, because it will be revealed by fire. The passage is about the day of judgment, not the day of a programming final. The analogy is asymmetric and partial.

But there is a real point in it. The work you have done this semester has been, in a sense, hidden — graded against rubrics, partial credit, AI assistance allowed in some places and not others, a thousand small accommodations to the realities of a college classroom. The final is the one rep that has none of that. You sit down with the tools you have, you build a small thing, and what you produce is what you produce. The fire reveals.

For the Christian student, there is one more thing to say. The fire reveals; it does not condemn. The point of the final is not to humiliate you. The point of the final is to give you an accurate account of where your skill is, so you can build on it. The students who treat a hard final as a calibration tool — here is what I do well; here is what I still need to drill — graduate from this course as real programmers. The students who treat it as a personal verdict, who spiral after a low score or get cocky after a high one, miss the point.

You are not your grade. You are the worker who is being shaped by the work. The grade is a piece of information about that shaping. Use it.

16.9 — Coach’s Final Word for Week 16 (and the Book)

You finished sixteen weeks of Coding 2. You finished, by now, thirty-two weeks of intensive Java and C++ training across both books. Most students don’t get this far. Of the ones who do, most can talk about programming but not actually do it. You can do it — you have shipped fourteen graded projects, ported between two languages, used AI as a partner without losing your judgment, written specs and tests and architecture documents that a senior engineer would read without wincing.

That is a rare thing. Cherish it.

A few words before the final, and before you close the book.

Programming, like every craft, requires lifelong practice. The skill you have at the end of this course is real but young. The students who keep it keep using it. The students who lose it lose it within a year. There is no third path.

The senior engineering skills compound. The reading muscle you built in Chapter 1 makes every code review you do for the rest of your career faster and better. The spec discipline from Chapter 2 makes every architectural decision more grounded. The testing habit from Chapter 4 catches bugs before they ship. None of these are temporary; all of these are permanent investments.

The AI tools will change. The judgment that directs them will not. Models you used this term will be obsolete in two years. The skill of knowing what good code looks like, recognizing when an answer is wrong, scoping a correction to its right size, holding the line on architecture — that skill is what makes new tools usable when they arrive. Build the skill; the tools will follow.

The apologetic frame, if it has spoken to you, doesn’t stop here. The questions the church asks about reading carefully, making promises, telling the truth, organizing knowledge, correcting in love, building well, claiming honestly — these are not exclusive to programming, and they are not finished after this semester. They are the lifelong questions of a thoughtful Christian who works in any field. The reps continue.

Show up rested. Trust your training. Submit something honest.

Then close the book. Walk out of the exam room. The work that begins after the final is the work that defines whether the sixteen weeks took root. Make sure it does.

See you on the other side.

Up next: Read the exercises for the sample-final reference. Then open Project 14 — the capstone. This is the last chapter of the book. After the final, you’re done.