How to pace a volume
How to pace a volume
There is no official morning/evening split and no required multi-volume day plan. This page is generic pacing advice for whatever single volume you are working on.
Suggested session shape (adapt freely)
Use whatever length fits your life. A useful internal split for a session:
| Slice | Rough share | Purpose |
|---|---|---|
| Concept | ~25–40% | Mental model, docs, examples in the chapter |
| Hands-on | ~40–55% | Code, rebuilds, experiments that can fail |
| Review | ~15–20% | Refactor, commit, write gotchas |
Each volume’s syllabus may hint at typical hours per day; treat those as author estimates, not rules.
Expert pacing rules (any volume)
- Protect gates. If a stage gate fails, stay there before advancing day numbers.
- Small commits. Prefer many small green checkpoints over one giant untested change.
- Stop on dangerous breakage. For systems work (e.g. NixOS), roll back and leave a note rather than “fixing” while exhausted.
- Weekly review (30–60 min). Refactor, delete dead experiments, write a few gotchas in your own words.
- One volume focus. If you also study something else (another volume or an unrelated course), that is your schedule—not this book’s curriculum design.
Weekly rhythm (suggested)
| Day type | What to do |
|---|---|
| Build days | New topic + hands-on from the chapter |
| Integration day | Mini-project or stage gate |
| Light day | Read primary docs; clean notes; fix one loose end |
Environment
Requirements are per volume (see that volume’s overview). Example:
- Go volume: Go 1.26.x, editor with
gopls, ability to run tests (later-race).
- NixOS volume: disposable VM or spare machine, disk for
/nix/store, flakes-capable Nix.
Calendar honesty
“90 days” names a shape, not a deadline. Stretching a volume over more calendar time is normal and often better.