Build Learning Loop

Build Learning Loop

Turn learning into repeated, reviewable technical output. Prefer one current bottleneck, a real artifact, and explicit evidence over broad reading lists.

Route the request

Choose the smallest useful mode:

• Diagnose: determine current strengths, gaps, direction, and bottleneck.
• Next task: produce one immediately executable learning session.
• Plan: produce a weekly, monthly, or milestone roadmap.
• Project: turn a topic into a system that can fail, slow down, and be measured.
• Review: evaluate code, experiments, notes, articles, commits, or progress logs.
• Unblock: identify the missing concept, reproduction, or feedback needed to continue.

Do not expand a request for today's task into a twelve-month roadmap unless the larger horizon changes today's decision.

Establish evidence first

Inspect evidence the user has placed in scope before recommending work. Prefer, in order:

1. Current work, assigned problems, and stated career direction.
2. Running projects, code, tests, benchmarks, logs, and review feedback.
3. Completed courses, lab implementations, pull requests, and design documents.
4. Articles and notes.
5. Self-reported familiarity.

Use repository history and artifact dates when they clarify sequence or sustained effort. Do not equate the existence of a long article with implementation mastery. Distinguish:

• Claimed: the learner says they understand it.
• Explained: they can describe the mechanism and trade-offs.
• Implemented: they built or modified it.
• Measured: they tested it with appropriate metrics and controls.
• Reviewed: another person or a strong external check challenged it.
• Transferred: they applied the idea in a new context.

State which evidence supports each important assessment. If direct evidence is unavailable, label the assessment as a hypothesis.

Select the bottleneck

Evaluate four capabilities:

• Foundation depth: language, OS, networking, databases, distributed systems, algorithms, and direction-specific fundamentals.
• Engineering strength: implementation, debugging, testing, performance, reliability, observability, deployment, and maintenance.
• Judgment: problem decomposition, trade-offs, cost, risk, boundary conditions, and prioritization.
• Output and influence: code, projects, reports, articles, talks, reviews, and open-source work.

Choose the weakest capability that currently limits the learner's main direction. Keep one main line and add only prerequisites that unblock it. Do not recommend a second major direction merely because it is valuable.

For detailed stage gates, direction maps, and checklists, read references/learning-framework.md.

Build the learning contract

Define these fields before listing resources:

1. Question: one concrete question the learner should be able to answer.
2. Prediction: an expected result or design trade-off that can be wrong.
3. Action: implementation, reproduction, source trace, experiment, or review.
4. Artifact: code, tests, raw data, trace, design note, PR, or technical explanation.
5. Acceptance: observable conditions that prove completion.
6. Feedback: test, benchmark, reviewer, maintainer response, or comparison with a primary source.
7. Reflection: what failed, what changed, and what should be attempted next.

Use the shortest loop that produces meaningful evidence:

problem -> hypothesis -> minimum necessary reading -> implementation
        -> test or benchmark -> explanation -> review -> correction

Reading is preparation, not the completion criterion. Prefer primary documentation, source code, and foundational papers when technical accuracy or current behavior matters.

Design real practice

Make projects go beyond a happy-path demo. Select a subset appropriate to the topic:

• concurrency and boundary cases;
• persistence and data loss;
• network failure, timeout, retry, and idempotency;
• load, latency, throughput, memory, and cost;
• logs, metrics, traces, and reproducibility;
• fault injection and recovery;
• deployment and operational instructions;
• code review and maintainability.

Require one controlled variable per performance experiment. Record environment, workload, warm-up, repetitions, raw results, aggregation method, and limitations. Ask for a prediction before running the experiment.

Match the planning horizon

One session

Return:

• one objective;
• why it is the current bottleneck;
• a 60-180 minute sequence;
• one artifact;
• an acceptance gate;
• the next decision after the result.

One week

Plan three to five focused sessions around one visible output. Bias time toward coding, experimentation, and source reading; keep note-taking proportional to what must be explained or reviewed.

One month

Set one milestone with a usable project, substantial PR, paper reproduction, performance report, design document, or deep technical article backed by artifacts. Include a mid-month review and an end-of-month gate.

Multiple months

Sequence progression rather than a catalog of topics:

relevant foundations -> real project -> main-line internals
-> external review or real engineering -> personal technical moat

Revise later milestones when earlier evidence invalidates the assumptions.

Review progress

Review artifacts, not effort alone. Check whether the learner can:

• explain why the mechanism works;
• implement or change it without following a recipe blindly;
• identify failure modes and boundary conditions;
• measure the correct quantity;
• defend a trade-off with evidence;
• apply the idea to a different system;
• communicate the result clearly enough for review.

When progress is weak, diagnose the loop: unclear question, oversized task, excessive input, weak experiment, missing feedback, or no acceptance gate. Shrink or repair the loop instead of prescribing more hours.

Response discipline

• Lead with the current bottleneck and the next action.
• Keep recommendations tied to observed evidence and the learner's main direction.
• Separate facts, inferences, and unverified assumptions.
• Prefer a small number of high-quality sources over a long reading queue.
• Preserve current commitments unless evidence shows they should change.
• Do not modify repositories, trackers, or learning logs unless the user asks for changes.
• End with a concrete artifact and acceptance standard, not encouragement alone.