Semester 4 Common Failure Modes
Use this page during weekly review and before the checkpoint gate. These are the ways a learner can appear busy while still failing the semester's real intent.
Failure Mode Table
| Failure mode | Repair evidence |
|---|---|
| Using low-level APIs without explaining ownership, lifetime, or failure behavior. | Add one concrete artifact proving the opposite: a trace, test, proof, benchmark, review note, or decision record. |
| Debugging by print statements only when traces, debuggers, or profilers are needed. | Add one concrete artifact proving the opposite: a trace, test, proof, benchmark, review note, or decision record. |
| Ignoring undefined behavior, resource cleanup, or error paths. | Add one concrete artifact proving the opposite: a trace, test, proof, benchmark, review note, or decision record. |
| Optimizing before measuring the actual bottleneck. | Add one concrete artifact proving the opposite: a trace, test, proof, benchmark, review note, or decision record. |
Weekly Review Prompt
At the end of each week, answer these in writing:
- Which failure mode was most tempting this week?
- What evidence shows you avoided or repaired it?
- What will you change in next week's study plan?
- Which older semester skill did this weakness depend on?
Do Not Advance If
- you can only describe the topic using resource titles rather than examples
- your artifact has no tests, traces, diagrams, or written reasoning
- you cannot explain the hardest mistake you corrected
- your checkpoint answers depend heavily on copied notes or solution videos