Assessment 2: getting a grip on something hard

Attack a real subject before you understand it, take one lesson per attempt, and let the list of what you are fighting grow out of those attempts. Run it for a fortnight and demonstrate it live

Due: 3 May 2027 · Weight: 25%

Attack something you do not understand yet, and let it tell you what it is made of.

Assessment 1 bought you the inside of thirty minutes. This one is the other half, and it is the half that decides whether a hundred hours is survivable.

Two routes, equally marked#

Simple — a sheet per boss, a wall of cards, a notebook with one line per attempt.

Coded — a boss tree that rolls up, an attempt log you can query, a view that shows you what is open.

Again neither scores higher, and if you built Assessment 1 on paper this is a good week to build in code, or the reverse. Doing both routes once across the two assessments is worth more to you than doing your comfortable one twice.

What it has to do#

• An attempt log. The centre of it. One entry per attempt: what you attacked, the one lesson, the one change for next time. Each lesson names something about the work rather than about your character — I was lazy is not a line, because no attempt can settle it.
• A list of fights that grew. Not one you wrote on day one. We will ask which entries you could not have named before you started, and a list with no such entries is a table of contents.
• Kill conditions, where you have earned them. One checkable sentence per fight, written once you have attempted enough to know what winning looks like. A fight without one eventually stays open forever, which is how this mechanism usually dies.
• Roll-up. A fight’s remaining work includes anything it turned out to contain, or the record flatters you.
• No fixed durations. Let the time fall out of the work. A length committed to in advance turns a campaign into a sentence.

What you submit#

Demonstrated live in the second half of the week 9 lecture, about six minutes:

1. The tree, and one boss walked through end to end — how it was named, what its kill condition is, what the attempt log says.
2. A boss that changed. Split into three, closed early, rewritten because the kill condition turned out to be uncheckable. A tree with no history of revision after two weeks of use is a tree you have not been reading.
3. What the mechanism told you that you would not otherwise have known.

The common failure#

Bosses that cannot die. Almost every unsuccessful submission has one obstacle that stayed open the entire fortnight, and in nearly every case the problem was not difficulty — it was a kill condition that could not be checked, so there was no possible event that would have closed it. Rewrite the condition; do not grind the fight.