What Not To Study Yet
A list of things to actively refuse, each with the condition that unlocks it.
This page exists because of a specific thing you said: "I frequently study advanced topics, but I tend to spread my attention across too many subjects and remain in knowledge-consumption mode." Every item below is genuinely interesting, and every one would feel like progress while being the opposite.
Refusing is a skill. The mechanism is: write the interest on the parking list, one line, and do not touch it. At each stage review, look at the list. Most entries will have stopped being interesting, which tells you what they were.
Table of Contents
- How To Use This List
- Not Yet — Machine Learning
- Not Yet — Systems
- Not Yet — Mathematics
- Not Yet — Tools and Infrastructure
- Not Ever, For This Journey
- The Meta-Rule
- References
How To Use This List
Three tests, applied when something new catches your attention:
- Does a project on the roadmap need it in the next 8 weeks? If no → parking list.
- Would learning it change what I build this month? If no → parking list.
- Am I drawn to it because it is interesting, or because the current milestone is hard? Be honest. The second is the most common reason to pick up a new topic, and it is the mechanism by which projects get abandoned.
Test 3 is the important one. Interest in a new subject spikes reliably around the point where the current project stops being fun — typically weeks 4–6 of a Medium project, which is exactly the debugging phase. That spike is not curiosity; it is avoidance wearing curiosity's clothes.
Not Yet — Machine Learning
| Topic | Why not yet | Unlocks |
|---|---|---|
| Scaling laws (Chinchilla, IsoFLOPs) | Meaningless until you can measure a training run's cost yourself | After P13-II, when you can compute FLOPs from your own graph |
| Mixture of Experts | An optimisation of a thing you have not built | After P01 and P13 both ship |
| RLHF, DPO, alignment training | Orthogonal to every mechanism here | Never, in this journey. A separate track |
| Quantization for LLMs | You will do quantization properly in P14 with roofline grounding | P14 (W111). Refuse until then |
| Distributed training (FSDP, tensor/pipeline parallel) | Requires P05's understanding and P13's framework | After P13-II and P05. A strong post-journey project |
| Diffusion models, VLMs, multimodal | Different architecture family; no mechanism here needs them | Never, here |
| Fine-tuning, LoRA, PEFT | You already use these professionally. Nothing new is exposed | Never, here |
| Prompt engineering, agents, RAG | Your day job. Zero marginal learning | Never, here |
| Neural architecture search | Requires a training budget you do not have | Never, here |
| Interpretability / mech interp | Genuinely fascinating; entirely orthogonal | After P01, as a separate track if you want it |
| Graph neural networks | P02 uses graphs for search, not for learning | Never, here |
| Reinforcement learning | P09 simulates users; it does not train agents | Only if P08's bandit extension |
The hardest refusal on this list is scaling laws, because it is the most intellectually satisfying ML topic and it is adjacent to everything. Refuse it until P13-II. The reason is specific: scaling-law work is entirely about the relationship between compute, data, and loss, and until you have built the thing that consumes the compute you are memorising other people's fitted constants. After P13-II you can compute \(C \approx 6ND\) from your own computation graph and check it, at which point the literature reads completely differently.
Not Yet — Systems
| Topic | Why not yet | Unlocks |
|---|---|---|
| Kubernetes internals, service meshes | Operations, not mechanism. You already operate these | Never, here |
| eBPF | A superb observability tool; a distraction from building your own instrumentation | After P12, when you know what it is instrumenting |
| io_uring | Its value is obvious only once you have measured syscall cost yourself | After P12's syscall measurement (W104) |
| Databases: query optimisation, SQL execution | P03 and P04 are storage engines, deliberately below the query layer | After P04. A legitimate next journey |
| Column stores, vectorised execution | Adjacent to P04 and genuinely tempting | After P04 ships. Parking list until then |
| Consensus beyond Raft (Paxos variants, EPaxos, Byzantine) | Learn one properly first | After P05. Then read Paxos and appreciate the difference |
| CRDTs and conflict-free replication | A different consistency model to the one P05 builds | After P05 |
| Formal methods, TLA+ | Would genuinely improve P05; a 40-hour skill inside its riskiest project | After P05, as a separate 2-week piece. See math.md |
| Network stacks, TCP internals, DPDK | No project needs packet-level work | Never, here |
| Compilers beyond P11 (SSA, register allocation, LLVM) | P11 stops at a bytecode VM on purpose | After P11-II. A strong follow-on |
| JIT compilation | The logical next step after P11-II, and a project in itself | After P11-II, as its own project |
| SMP kernel work | Multiplies P12's difficulty; P12 is single-core by design | After P12 |
| Security: sandboxing, capabilities, isolation | P12 does basic isolation only | After P12 |
| WebAssembly runtimes | Interesting, adjacent to P11, not needed | Never, here |
Two of these are scheduled rather than refused, and it is worth noting the difference. eBPF and io_uring both become dramatically more meaningful after P12, because both are answers to costs you will have measured. Reading about io_uring before measuring a 128 ns syscall is reading a solution to a problem you have not felt.
Not Yet — Mathematics
Covered in detail in math.md. The summary: measure theory, real analysis, convex optimization theory, category theory, information geometry, spectral graph theory, statistical learning theory, and Bayesian inference are all excluded, each because no project on the roadmap needs it.
The general principle: mathematics in this journey is a tool acquired at the moment of use. Sixty hours across 34 months, scheduled per topic, with a stated stopping point. A mathematics curriculum run in parallel would be a second journey, and running two is the failure mode.
Not Yet — Tools and Infrastructure
| Topic | Why not yet | Unlocks |
|---|---|---|
| A new editor / IDE / dotfiles overhaul | The most seductive form of procrastination in software | Never. Use what you use |
| A note-taking system (Obsidian, Zettelkasten, etc.) | notebook/ is markdown in git, plus the review queue. That is the system | Never |
| Nix, Bazel, containerised dev environments | Reproducibility here means pinned versions and a documented command | Only if a real reproducibility failure occurs |
| CI/CD for personal projects | A local make test is sufficient at this scale | If a project gains external contributors |
| A personal website or blog platform | Write in markdown; publish later. See portfolio.md | W20, when you have a first result worth publishing |
| Cloud infrastructure for experiments | Every project is designed to run on one laptop | Only P14, only if you need a GPU you do not have |
| Learning a fifth language | Four is already a lot of context switching | Never, here. See languages.md |
| Rewriting an earlier project in a nicer language | Explicitly forbidden | See the rewrite exceptions |
Dotfiles and tooling deserve their own warning. There is no faster way to convert a week of implementation into a week of nothing than deciding your setup needs improving first. If your editor works, it is good enough. If it does not, fix the one thing that is broken and stop.
Not Ever, For This Journey
Not because they are unworthy — because they belong to a different journey, and mixing them in would be the breadth failure this whole structure exists to prevent.
- Frontend, UI, UX work beyond a plot and a five-minute demo video
- Product management, market analysis, startup strategy
- Certifications of any kind
- Conference talks before you have a result — the portfolio plan has a sequence, and it starts with the artifact
- Open-source contribution to large projects — worthy, and a different time commitment. Your own repositories are the portfolio
- Competitive programming — a different skill with genuinely poor transfer to systems design
- Reading a systems paper a day — the single most seductive item on this page. Reading is capped at 15% and tied to milestones for a reason. A paper-a-day habit produces the feeling of expertise and none of the ability, and it is precisely the consumption mode you asked to escape
The Meta-Rule
Anything that makes you feel productive without producing a running artifact is a distraction, however sophisticated it looks.
Three specific patterns that pass as work and are not:
- Reading a paper about a system you are not building. Feels like learning; produces recognition rather than ability. You have done this for years and it is why you are reading this plan.
- Improving tooling for work you are not doing. A better benchmark harness for a benchmark you have not run.
- Planning the next project while the current one is unfinished. The most convincing form, because planning genuinely is work — just not this week's.
The test for all three: at the end of this session, will something exist that did not exist before, and does it run?
References
- Newport, C. So Good They Can't Ignore You. Business Plus, 2012. The craftsman mindset and the argument against following interest wherever it leads.
- Hamming, R. W. You and Your Research. Bell Communications Research, 1986. On the discipline of working on important problems rather than merely interesting ones, and the observation that the difference is mostly about what you decline.
- Ericsson, K. A. et al. The Role of Deliberate Practice in the Acquisition of Expert Performance. Psychological Review 100(3), 1993. Why targeted practice on a known weakness beats broad exposure.
- Bjork, R. A., Bjork, E. L. Desirable Difficulties in Theory and Practice. JARMAC 9(4), 2020. Why the easy, pleasant activity (reading) produces worse retention than the hard, unpleasant one (retrieval and construction).
- Sweller, J. Cognitive Load Theory. Springer, 2011. The capacity argument for one project at a time.