Appendix B — Surviving the Accelerated Course

“…let us run with endurance the race that is set before us.” — Hebrews 12:1

“The session you finish beats the session you planned.”

Read this before Week 1, and again the first time a week goes wrong.

This appendix is not about C++. It is about what actually decides how this course ends for you: whether you can carry twelve hours a week, alone, for eight weeks. That is a separate skill from programming, almost nobody teaches it, and it is likelier than pointers to be why a student disappears.

B.1 — The Honest Arithmetic

The sixteen-week Coding 1 runs about six hours a week for sixteen weeks — roughly ninety-six hours. This edition covers the same sixteen chapters, nothing cut, in eight weeks. Those hours have to go somewhere, so they go into twelve hours a week. There is no compression technology; the material did not get smaller, your calendar did.

Twelve hours a week is a part-time job, not “a class.” If you work forty hours and take two other courses, twelve more means giving up something real — evenings, a weekend morning, a hobby, sleep. One of those is a bad answer; the other three are yours to pick.

Do this before Week 1, on a real calendar, not in your head.

1. Block four three-hour appointments in the coming week. Give them names, not “study.”
2. Write down what each block displaced.
3. Do the same for the seventh week out — the one that already has a wedding or a shift swap in it. That is the week that ends courses.

If you cannot find twelve hours in a normal week without lying to yourself, take the sixteen-week Coding 1 instead — same competencies, same projects, a calendar you can hold.

Coach’s Note — A finished sixteen-week course beats an abandoned eight-week one, every time, and nobody who hires you will ever ask which calendar you used.

One warning: Weeks 4 and 8 are not lighter. No project, but each carries a 50-point quiz plus a 100-point practical.

B.2 — A Weekly Rhythm That Works

Twelve hours split four ways, about three hours each — not two sittings of six, not one heroic Saturday.

Each chapter’s Your Week at a Glance table is that week’s authoritative version.

Why splitting beats a marathon. Reading and typing hold up for hours; debugging does not. By hour five you are changing lines at random, and the bug that is invisible then is often obvious ten minutes into the next session, once you stop reading what you meant to write. A marathon also has one point of failure: if your block is Saturday and Saturday goes sideways, the week is gone.

A sample week on real days

Say the project is due Sunday at 11:59 p.m.; check Canvas for your real dates.

Sunday is a block you schedule and hope not to spend; something will overrun, and then you spend the reserve instead of the deadline. And never put Sessions 3 and 4 on the same day: you cannot proofread code you wrote twenty minutes ago.

B.3 — How to Read a Compiler Error

This is the highest-value skill for a student with nobody in the room, and most beginners never learn it — they skim for a line number and guess. Read the whole message; it usually contains the answer. Real GNU g++ output, compiled with g++ -std=c++17 -Wall -Wextra:

tally.cpp: In function 'int main()':
tally.cpp:6:47: error: expected ';' before 'cout'
    6 |     cout << "Witnesses: " << witnesses << endl
      |                                               ^
      |                                               ;
    7 |     cout << "Done." << endl;
      |     ~~~~

Five pieces. tally.cpp, the file. In function 'int main()', the where — with ten functions in a file this saves you nine. 6:47, line 6 and column 47 — the column is the part people skip and it is often the whole answer. error:, the severity — it did not compile, where warning: means it did and you should still fix it and note: is a hint. And the echoed line with ^ — the caret marks the column, below it g++ prints the character it wants, and ~~~~ marks the token that confused it.

”expected ’;’ before …” means look at the line ABOVE

The token the message names — cout — is on line 7. The place the semicolon goes is the end of line 6. The compiler reads forward until something becomes impossible: the semicolon was missing on line 6, but nothing was wrong yet, since endl could have been followed by more of the statement. So expected ';' before <something> means the fix goes at the end of the line above the something. Follow the caret, not the token.

The first error is the real one

total.cpp:8:9: error: 'total' was not declared in this scope
total.cpp:11:28: error: 'total' was not declared in this scope

Two errors, one cause: there is no int total = 0; before the loop. Add that line and both vanish. A missing include, an unclosed quote, a missing brace — each produces a pile, and the pile is one bug in a costume. Fix the first error, recompile, do not read past it.

javac speaks a different dialect

FleetDemo.java:5: error: cannot find symbol
            total = total + scores[i];
            ^
  symbol:   variable total
  location: class FleetDemo

Same information rearranged: no column in the header, a count at the end of the run, and two bonus lines — symbol: is what javac could not find, location: is where it looked. On a variable that means undeclared or misspelled; on a method, wrong name or argument types. Java’s semicolon complaint reads error: ';' expected and helpfully points at the line the semicolon belongs on.

Every chapter has a Common Bugs section with the real text of that week’s errors: §1.22, §2.18, §3.20, §4.13, §5.19, §6.19, §7.18, §8.15. Read the current week’s before you need it.

B.4 — The Getting-Unstuck Ladder

You will get stuck, and there is no hand to raise. Climb a ladder, one rung at a time, with a clock. Being stuck for thirty minutes is normal and productive. Being stuck for three hours alone is a choice — not noble, just an expensive route to the same answer.

Rung 1 — Read the actual error text, all of it, and find the FIRST error. — 2 minutes. Scroll up. Read the file, line, column, message, and caret, in that order, then look at the line above the one named. Many of the first four weeks’ errors die right here.

Rung 2 — Reproduce it in the smallest possible program. — 10 minutes. New blank file. Rebuild only the broken part, with hard-coded values instead of cin. Ten lines that show the bug beat two hundred that contain it: if every average comes out zero, the reproduction is int hits = 7; int total = 9; double rate = hits / total; and a cout, which prints rate = 0 and leaves the bug nowhere to hide. Often it reveals itself while you cut the program down.

Rung 3 — Rubber-duck it out loud. — 5 minutes. In complete sentences, to an object, not in your head. “The loop starts at one and runs while i is less than or equal to count, so it runs…” — and there it is, out of your own mouth. The bug is nearly always the gap between what you think the code says and what it says.

Rung 4 — Re-read the section that introduced the construct. — 10 minutes. Not the whole chapter — the section that taught the broken thing, plus that chapter’s Common Bugs (Week N Edition): §1.22, §2.18, §3.20, §4.13, §5.19, §6.19, §7.18, §8.15. Those exist so a student alone at 11 p.m. can look up the literal string the compiler printed.

Rung 5 — Check the glossary. — 3 minutes. Appendix D defines every term in this book, and many “I’m stuck” moments are really “I don’t know what this word means.” Half-remembered syntax is Appendix C; a tool problem, Appendix A.

You are now about thirty minutes in. If you are still stuck, stop working alone.

Rung 6 — Post to the discussion board, then keep working. Use the template in §B.5 and go back to the project; do not sit and refresh. Someone in your cohort hit this wall this week, and a well-shaped post usually gets an answer the same evening. A vague one gets a question back, costing another day.

Rung 7 — Email the instructor. Same template, plus your OnlineGDB share link and the tier you are targeting. Subject: [Accelerated Coding 1] Wk3 — <one-line symptom>. Send it once you have genuinely climbed rungs 1–6, not three days later out of politeness. Three days is a twentieth of this term.

One boundary: these rungs apply to chapters, reps, and projects. Once you open Part B, help narrows to logistics — nobody debugs your practical, which is why rungs 1–5 are worth drilling now, on the reps, where they are free.

B.5 — How to Write a Help Request That Gets Answered

Copy this and fill it in. The same shape works for the discussion board and for email:

Title: [Wk3] linear_search returns -1 for a name I know is in the array

What I'm trying to do:  find a manuscript by name in an array of 5.
What I expected:        Codex Sinaiticus -> 4
What actually happened: Codex Sinaiticus -> not found
Exact error/output:     (copy-pasted, all of it, not retyped)
Smallest code that shows it: (8-15 lines, hard-coded data, no cin)
What I already tried:   printed the array inside the loop (all 5 names present,
                        spelled right); checked Week 3's Common Bugs, no match.

Why each line earns its place:

• The title carries the week and the symptom. [Wk3] says whether a reader knows this material yet; the symptom — not “help!” — means whoever has already solved it recognizes it while scrolling, and the next student to hit it can find your thread.
• What I’m trying to do stops a reader solving a different problem. Half of all bad answers are correct answers to the wrong question.
• Expected vs. happened is the definition of a bug. Without both, nobody can tell whether the program is broken or the expectation is.
• Exact text, copy-pasted. error: expected ';' before 'cout' is searchable and specific; “it says something about a semicolon” is neither.
• The smallest code. Nobody reads a 200-line project at midnight; ten lines get read at once. This is why Rung 2 comes before Rung 6.
• What I already tried keeps a reader from suggesting what you did an hour ago.

Fill it in even when you never post it; writing it solves the problem often enough on its own.

B.6 — The Recovery Plan for a Week You Lost

You will lose a week, or most of one. Here is the plan, no lecture attached.

Triage, in order.

1. Do the current week’s reps before the missed week’s project. This feels wrong and it is correct: Chapter 4 is built on Chapter 3’s reps, not Chapter 3’s project. Skip the reps and you are not one week behind — you are compounding.
2. A Normal tier submitted late beats a Hard tier never submitted. Drop your tier the moment you are behind. Medium and Hard are extra credit; Normal is the grade.
3. Submit something. A partially working Normal tier earns rubric points; an empty submission earns none.

Cut in this order: Medium and Hard tiers, immediately; the “break it on purpose” exercises; re-typing examples you already understand; the polish pass. Never cut the current week’s reps or Checkpoint — the Checkpoint is the ten-minute diagnostic that tells you whether the next three hours belong to the project or to re-drilling.

The arithmetic, so you can decide instead of panic. Projects are 50% of the grade split across six, so one project is worth about 8.3 percentage points of your final grade. One zero is survivable; two changes what course you are in. Each exam is 25%, three projects’ worth in one week, which is why exam weeks get protected first.

A concrete one-lost-week plan. Spend this week’s twelve hours on the current week, sessions 1–4 unchanged. Steal four more for the missed project at Normal tier only, using the previous chapter’s worked example as a skeleton. Do not also make up the missed reps; take that chapter’s Checkpoint cold and re-drill only what you fail.

When to email instead of digging. Send it if you have lost two weeks rather than one; a third of the course does not get recovered in silence. Send it if you are going to miss an exam window, and send it before the window opens. Four lines is enough: which week you lost, why, what you have already done, what you propose. You do not owe a story. You do owe a plan.

B.7 — AI as a Sparring Partner

The rule in this course, exactly as the README states it:

• First, attempt every concept, exercise, and project yourself, from scratch, until you can write it without looking.
• Then, use AI to review your code, explain an error, or expand your thinking.
• Never submit code you cannot explain line by line out loud.

Here is the failure mode, worth naming before it finds you. A student uses AI well enough to keep up: the projects come out clean and the grades are good through Week 3. Then Week 4 arrives — Part B, a blank file, three focused hours, AI off on the honor system, and a written section asking them to explain their own design decisions. And they cannot start. Not from dishonesty; they read every submitted line and it made sense. But reading code you did not write feels exactly like understanding, and it is not the same motor skill as producing it from nothing. Recognition is cheap and fast; recall is expensive and slow, and recall is the only thing the practical measures.

The diagnostic is one question: can you open a blank file and start? Not finish — start. The includes, the main, the first loop, without looking at anything. If you can, you have recall. If you sit there, you have recognition — and you found out in Week 3 rather than on the exam.

Good uses, after an honest attempt: “explain this compiler error in plain English”; “here is my working code, what bugs do you see that I don’t”; “quiz me without showing me the answers.” Uses that cost you the course: writing the reps or the project, or producing code you read once and submit. Both practicals require a written component explaining your design decisions, and code the author cannot explain is treated as not-submitted. Not a trap — just what the exam measures.

Coach’s challenge, once a week: write one program with AI turned off entirely. A rep from exercises.txt counts. Twenty minutes counts. That one rep a week proves the skill is actually yours.

B.8 — Studying for the Week 4 and Week 8 Exams

Both exams have the same two-part shape, and each half rewards a different drill.

Each exam totals 150 points and is 25% of your grade. Part B is twice Part A on purpose: the auto-graded half checks that you can read code, the practical checks that you can write it, and only one of those is the actual job.

Part A: trace on paper

Part A asks what does this print and what is x after this loop with no compiler in front of you, so practice with no compiler in front of you. The drill: take a program from a chapter’s code/ folder, cover the output, and on paper draw a table with one column per variable and one row per iteration. Fill it in by hand as the machine would, then run it. Try it now:

#include <iostream>
using namespace std;

int main() {
    int total = 0;
    for (int i = 1; i <= 5; i++) {
        if (i % 2 == 0) {
            continue;
        }
        total = total + i;
    }
    cout << "total = " << total << endl;
    return 0;
}

Two columns, i and total, five rows. The real output is total = 9. If your paper said 15, you skipped the continue. Do this fifteen or twenty times and Part A stops being a test. Do it on screen and you will cheat without meaning to by running the program halfway through — and the half where you cannot is the point. Also cause the errors on purpose: reproduce three of that week’s Common Bugs entries by hand, and “which line causes the error” becomes recognition.

Part B: rebuild from a blank file

The single highest-yield hour in the course. The drill: open a blank OnlineGDB file and the brief for a project you already submitted. Set a timer for sixty minutes and rebuild the Normal tier without looking at your old code, then compare.

What you learn is not “I remember this.” It is which pieces you cannot produce cold — usually the syntax of the thing you wrote once, the input-validation loop, and the function signature with the reference parameter. Those are your study list.

For the midterm, rebuild P1, P2, and P3 at Normal tier — Weeks 1–4’s material: I/O, types, control flow, functions, arrays, strings, structs. Chapter 4 ships code/sample_midterm.cpp as a closed-book dress rehearsal; do it in about sixty minutes first. For the final, rebuild P4, P5, and P6 — and rebuild the C++ ones in Java, since the final practical is Java and translation is what Week 7 built. Chapter 8 ships code/PracticeFinal.java for the same purpose.

Inside an exam week, sessions 1 and 2 stay ordinary read-and-reps — Week 4’s structs and Week 8’s abstract classes are on the exam. Session 3 is trace drills, then Part A: take it first, because it is a diagnostic that hands you explanations the moment you submit. Session 4 is Part B. Chapter 4’s Your Study Plan (§4.18) and Chapter 8’s The Study Plan for the Days You Have (§8.14) give the day-by-day version.

One rule for the day of Part B: learn nothing new. Cramming a fresh concept an hour before a three-hour practical does not add a skill; it adds anxiety and eats the hour.

B.9 — The Isolation Problem

Name it plainly: asynchronous online courses have lower completion rates than the same course taught in a room, and the students who disappear are usually not the ones who could not do the work. They are the ones for whom nothing happened when they stopped — no empty seat, nobody asking Thursday why they missed Tuesday. After two weeks of silence, coming back felt worse than not coming back.

That is structural, not a character flaw, and it has structural fixes. Use three of these four.

1. A fixed schedule, on the calendar, with alerts. Same four blocks, same days, same hours, for eight weeks. Not “when I get time” — that time does not exist. A ritual removes the decision: you do not decide about Wednesday at seven, you just go.

2. The discussion board, weekly, whether or not you are stuck. Post something every week and answer somebody else’s question — you learn more explaining a bug than solving one. Being known in a cohort, even faintly, changes whether you come back after a bad week. It is the closest thing this course has to a room, and it only works if people are in it.

3. One accountability partner. Find one person on the board in Week 1 and propose this: two texts a week, Wednesday and Saturday, two questions — what did you ship? and what are you stuck on? No code sharing, no meeting, no friendship required. The mechanism is that on the Saturday you did nothing, you have to type that to a human being.

4. Visible progress. Put a paper checklist where you will see it — eight rows, four boxes each, thirty-two boxes for thirty-two sessions — and check them with a pen. Online you have no ambient evidence that you are moving; the checklist substitutes for the room noticing you.

One rule for the day you skip a session: it is for scheduling the make-up, not for deciding how you feel about the course.

B.10 — Coach’s Final Word

Find the twelve hours on a real calendar before Week 1, or take the sixteen-week course and finish it. Four sessions, not one marathon. When you get stuck, climb the ladder with a clock — thirty minutes alone, then ask, in the shape that gets answered. When a week goes wrong, protect the reps, drop the tier, submit something, and email early rather than late.

None of that is about being smart. It is about showing up on a schedule and knowing what to do in the first ten minutes of being stuck — both trainable, both trained by repetition. Eight weeks is fifty-six days and about ninety-six hours: genuinely achievable, and genuinely a lot. The students who reach the other side are not the ones who never fell behind. They are the ones who had a plan for the week they lost.

Up next: If your tools are not set up yet, that is Appendix A — fifteen minutes, and the only setup in this course. Then open Chapter 1 and start the first rep.