Breaking Projects into Parts
also Decomposition · Sub-projects · Project decomposition · Breaking into smaller parts
Splitting a complex project into independently judgeable sub-projects, each with its own goal and pass/fail evaluation, so success or failure is detected early and often.
In CF, learning anything requires two tools: doing simple things, and dividing complex things into simpler parts. Repeat the dividing until each part is simple enough to learn directly. There are usually many valid ways to split the same project (touch typing can be divided by row, hand, finger, or vowels vs. consonants); you need only a reasonable division, not the optimal one.
What makes a part a genuine sub-project is that it can be judged mostly in isolation. Each sub-project needs its own goal, and you evaluate its success or failure against that goal. This is the crux of CF’s take: decomposition exists to enable frequent, early evaluation, not merely to make work feel manageable. The rule of thumb is that learning sub-projects should reach a verdict within a week at most, with multiple judgments per day being common and good. A sub-project’s length is the time to evaluate, not the time to succeed — failing in five days is on time and useful, because you avoided spending months before discovering the failure.
CF ties this to a target success rate well above 50% (often 80–90%+): when a part fails, halve the next part’s difficulty (exponential backoff) and never chain failures. Decomposition also lowers demand on conscious attention, letting each chunk be practiced and automatized before combining.
The named opposition is the vague, multi-year goal with no milestones — “develop AGI” — which CF diagnoses as a defense mechanism for avoiding any evaluation of failure. Compare finding breakpoints for choosing where to divide.