Dinesh/ Blog
systems

The 6-Month Learning Plan · 130 Sessions and a Foundations Lab

A coherent 130-session, 16-module engineering curriculum with 26 revisions, a protected ten-lesson Foundations Lab and honest pacing and prerequisite boundaries.

30 min readChecking device speech…
Lesson preparation & details

Level: beginner

By the end, you should be able to

  • Choose an appropriate starting lesson
  • Distinguish checked behavior from unsupported guarantees
  • Produce a tested local-system capstone

Sources checked: . A source check does not change the publication or update date.

Editorial review: · What review means

In this article · 29 sections

This familiar address now offers two ways to study: a ten-lesson runnable Foundations Lab and the broader engineering subject directory below. The lab culminates in a local job-event notebook with an evidence-based rubric; it does not replace Python, mathematics, advanced algorithms, data engineering, distributed systems, ML or cloud subjects. The historical six-month schedule is an optional pacing idea, not a guarantee of mastery or a running reminder service.

This is a personal learning laboratory. The aim is to know why the program works, where it stops working, and what a test actually establishes. You will derive algorithms, challenge them with small oracles, and carry the same habits into transactional state and retry handling.

What you need

An existing Python 3.10+ installation, a text editor, basic arithmetic, and enough terminal familiarity to run python3 filename.py. The original lab review recorded Python 3.12.3; this hub’s shallow-copy example is rerun in the current review environment recorded in the evidence. The lessons use the standard library and in-memory SQLite; there are no paid APIs, cloud accounts, package-install exercises or required servers. If Python is not installed, use the official distribution instructions for your operating system rather than copying an archived setup script.

The first lesson explains names, mutable values, functions and exceptions as they arise. It is not a complete Python syntax reference. Use the official Python tutorial for the exact container semantics and follow the cited reference when an API behaves differently from your intuition.

The route

StageLessonWhat you hand back
01Contracts and PythonA normalizer, mutation policy and negative-input tests.
02Counts and prefixesAn optimized algorithm compared with a slow independent oracle.
03Search and windowsA discard argument and a counterexample when its precondition fails.
04Stacks, queues and heapsAn explicit removal policy and duplicate-value tests.
05GraphsShortest-hop paths and a dependency order or cycle rejection.
06Dynamic programmingState meaning, recurrence, base cases, evaluation order and complexity.
07SQL and transactionsA schema, correct zero-event report and rollback test.
08RetriesA lost-acknowledgement trace and stable-identity contract.
09Bounded workAn admission policy and a conservation equation.
10CapstoneA local notebook with a failure-injection suite and assessed limitations.

Follow the table in order for the whole course. The explicit prerequisite graph allows a shorter systems route: after contracts and counts, study SQL, retries and bounded work, then return through search/windows and frontiers to graphs before the integrated capstone. Those intermediate prerequisites still apply on the shorter route. DP is a deliberate algorithm branch rather than a prerequisite for every database example. Dependencies indicate conceptual needs, not a demand to read every prior page.

One complete learning cycle

Read the contract. Predict a result on paper. Run the smallest example. State why it worked. Change one assumption and find a counterexample. Finally, write a test that would detect the mistaken implementation you were tempted to write.

For example, a shallow list copy has a precise scope. This executable check is a model of a study artifact:

source = [["queued"]]
copy = source.copy()
copy[0].append("running")
assert source == [["queued", "running"]]
copy.append(["done"])
assert len(source) == 1

The result supports two narrow claims: the inner list is shared, while the outer list is different. It does not support “copying is broken” or “all Python objects are passed the same way.” The official list-copy contract says the copy is shallow; the trace explains what that means here.

You can use a notebook entry with four headings: claim, assumption, check, limitation. Reading is not completion. A correct example is not a proof. A compiler accepting an article is not evidence that its technical claims are true.

Exercises and answer sketches

  1. You can write Python loops but have never designed a SQL table. Where can you start? Sketch: attempt the contracts exercise first; if its semantics are clear, proceed through counts and then take the systems branch. Do not skip transaction ownership merely because the SQL syntax looks familiar.
  2. A test passes once. What should you record? Sketch: the exact input, expected/observed result, command, environment and the property the test challenges. Separate that observed case from an all-input correctness claim.
  3. You have only a short study session. What is a useful stopping point? Sketch: one written invariant and a counterexample or a failing regression test. An arbitrary number of pages read is less inspectable.

The capstone rubric allocates points to contracts, algorithms, relational correctness, failure handling and reproducibility. Mandatory invariants override the score: a partial transaction or duplicate counted event is a failed capstone, not a cosmetic deduction.

What changed, and what did not transfer

Useful original subjects are being substantively corrected at their own addresses. The exact recovery sources remain private, and the compact lab is not treated as an equivalent replacement for omitted objectives. Some restored lessons still await complete review; their routes say so rather than presenting pending material as validated.

The subject directory is a map of intended breadth, not a certificate that every linked framework, cloud environment or model experiment has been reproduced. Follow each lesson's publication state, cited source contract and execution limits. A conceptual explanation can be useful without a deployment claim; a missing explanation cannot be excused by saying no deployment was run.

This page does not represent a calendar commitment, a promise that all 130 sessions are already accepted, weekly reminders or a guarantee of interview outcomes. Completing the route also does not certify proficiency for a particular employer or role: assess that against role-specific work samples, independently reviewed designs and unfamiliar problems. Use the published learning map for currently admitted lessons and the directory for the full subject scope.

For a repeatable algorithm-only practice loop, see the practice route.

Python, mathematics and algorithm routes

The compact Foundations Lab remains intact. It is a runnable core, not a replacement for the broader subjects below. Use the focused family lessons for derivations, variants, failure cases and practice.

Revision and transfer

Use the 26 revision articles to combine subjects. They now include worked bounded models as well as assessment prompts; their execution evidence does not claim to reproduce cloud services or optional ML runtimes.

How to use this

The six-month name describes an optional 26-week pacing envelope, not a guarantee that 130 subjects can be mastered from zero background in one-hour units. Start at setup if you need it, and use each lesson’s textual prerequisites plus explicit graph edges. A 30-second explanation can expose a gap but is not a validated prerequisite exam.

The module order below is a broad dependency-aware spine: learn Python/container contracts before algorithms, probability and linear algebra before model derivations, HTTP and process/network concepts before distributed designs. Numbered order is a navigation convention; check prerequisites when crossing into a specialized branch. The graph checks explicit public prerequisites and cycles, not all implied background or a generated calendar.

For a concept session, choose the 60-minute protocol in the learning-system essay: 2 prediction, 8 intuition, 10 visual, 20 code/derivation, 8 production boundaries, 12 retrieval and correction. It totals 60, but difficult topics need additional sessions. Use a revision article’s own 90-minute agenda on a later day; protect rest and slack instead of treating missed work as a reason to pretend completion.

The ten-lesson lab above is a runnable composition route. The sixteen modules below retain the broader original subjects; they are not replaced by the lab. Each module has an entry condition and an inspectable outcome so the list is a curriculum rather than a bag of links.

The 16 modules

The broad syllabus remains represented alongside the smaller runnable lab. This hub review checks the route, module ranges and prerequisite explanations; it does not establish that every linked lesson has completed its substantive review. Publication status is an editorial signal, not proof of technical correctness. Read each target’s evidence, prerequisites and execution limits before relying on it; no cloud, GPU or distributed-system demonstration is certified by this directory.

M00 · Setup & Tools

S001–S004; 4 sessions. Entry: basic computer access; no assumed Python fluency. Build a reproducible local environment, inspect shell commands before execution, save a small change in version control, and locate authoritative versioned documentation. Exit with a minimal project, a recoverable change and a documented command; installing a tool does not prove you can use it safely.

M01 · Python Foundations

S005–S014; 10 sessions. After setup, trace names/objects and control flow before combining functions, containers and classes. Compare composition with inheritance under an actual interface, handle exceptions deliberately, package code and test/type-check its contract. Exit with a small module, mutation policy, ordinary/negative tests and an explanation of what runtime checks versus annotations establish.

M02 · Math Foundations

S015–S022; 8 sessions. Use arithmetic and small Python functions to count operations, reason with sets/logic, interpret vectors/matrices, derive derivatives/gradients and handle probability/statistical uncertainty. Exit by deriving a scalar loss gradient, checking it numerically and interpreting a confidence interval under stated assumptions. Gradient descent is an important method, not the one optimizer behind all ML; asymptotic analysis does not replace measurement.

M03 · Data Structures & Algorithms

S023–S034; 12 sessions. Require container semantics, functions and basic cost reasoning. Contrast arrays, hashing, pointers and frontier orders; then connect recursive tree/graph traversal to sorting/search and recurrence/greedy choices. Exit with a tested implementation, invariant and complexity argument. Hash-table lookup is not an unconditional O(1) guarantee or a measured fraction of all interview problems. The separate 65-lesson route supplies deeper variants.

M04 · Databases & SQL

S035–S044; 10 sessions. After data/container basics, model keys and relationships before joins/aggregates/windows, recursive queries, indexes, transactions and plan inspection. Exit with a schema, zero-row/duplicate-aware reports, a rollback example and a query-plan interpretation. An index is a workload tradeoff, not always the biggest performance lever; transaction isolation and actual database/version matter.

M05 · Data Engineering

S045–S054; 10 sessions. Build on SQL and basic systems vocabulary. Model analytical grain, batch/stream time, partition/shuffle work, event logs, orchestration/retries, warehouse transformations, table formats, quality and governance. Exit with a pipeline contract specifying keys, lateness, backfill, idempotence, lineage and cost attribution. Tool names are alternatives with version-specific guarantees, not proof that Spark or Kafka runs every system.

M06 · Backend & APIs

S055–S059; 5 sessions. Require basic functions, data representation and command-line use. Trace HTTP requests/caching, design resource and idempotency contracts, compare GraphQL and typed RPC, and separate authentication from authorization. Exit with an API example, error model and authorization boundary. Binary serialization alone does not prove a service faster; protocol, workload and deployment decide.

M07 · Systems & Infrastructure

S060–S069; 10 sessions. Use the backend path to motivate processes, threads, memory, sockets, DNS, balancing, caches/CDNs and containers before orchestration, cloud identity/networking and infrastructure-as-code. Exit with a resource/failure diagram and a reversible deployment plan with secret and access boundaries. A Dockerfile does not guarantee portability, and a few Kubernetes options do not certify production readiness.

M08 · Distributed Systems

S070–S076; 7 sessions. After storage, transactions and networking, reason about partitions/latency, replication/consistency, consensus, sharding, queues and regional failover. Exit by tracing a failure where the promised consistency or delivery property matters and naming quorum/ownership/recovery assumptions. Replication is not a backup, and a multi-region label does not prove disaster recovery.

M09 · Observability & SRE

S077–S080; 4 sessions. Use the request path and failure model to choose metrics/logs/traces, instrument a boundary, define SLIs/SLOs and an error budget, then draft an incident/runbook/postmortem loop. Exit with a denominator-correct reliability calculation and an actionable alert linked to user impact. Three telemetry categories are a useful lens, not an exhaustive proof of observability.

M10 · Security

S081–S083; 3 sessions. Build on APIs and networks. Trace identity/session/password boundaries, certificate trust and TLS, then threat-model input, access, secret and dependency risks. Exit with a concrete abuse case, prevention/detection layers and residual risk. OWASP categories are not the only ten ways an application can be compromised, and this module is not a security certification.

M11 · Classical ML

S084–S095; 12 sessions. Require Python, probability, statistics and matrix/gradient foundations. Establish train/validation/test separation; derive linear/logistic models; compare regularization, bias/variance, trees/ensembles, metrics, preprocessing, imbalance and model selection. Exit with a leakage-safe experiment and a metric/threshold justified by error cost. Accuracy can be appropriate; no single model is always the tabular winner.

M12 · Deep Learning

S096–S105; 10 sessions. Use linear algebra, chain rule and ML evaluation to build neurons/MLPs, derive backpropagation and optimizers, then use tensor/autograd abstractions before regularization, convolution, recurrent state, embeddings and transfer. Exit with shapes, a gradient check and a held-out evaluation plan. Normalization and dropout do not automatically prevent memorization; architecture names do not settle generalization.

M13 · NLP & Transformers

S106–S115; 10 sessions. After neural networks and embeddings, connect tokenization to attention/QKV, head structure and positional information, then encoder/decoder families, sampling, scaling and efficient attention. Exit by computing a masked attention example, explaining token versus byte counts, and comparing exact versus approximated operators. Bigger models and more heads are not universal quality guarantees.

M14 · LLMs & Applications

S116–S125; 10 sessions. Require transformer/serving vocabulary, retrieval/data and API security concepts. Develop prompting, chunking/indexing, retrieval/reranking, vector search, tools/orchestration, evaluation, adaptation, serving and multimodal boundaries. Exit with evidence-grounded answers, a calibrated evaluation slice, a cache/cost budget and permission limits. RAG is not proven to cover a fixed percentage of applications; source grounding does not guarantee truth.

M15 · System Design

S126–S130; 5 sessions. Bring together APIs, storage, reliability, security and AI evaluation. Derive requirements/capacity before committing to a shortener, chat, feed or AI-chat design, then revise one assumption and trace the change. Exit with a design document, alternatives, failure timeline, acceptance criteria and a measurement plan. A 45-minute mock is a practice format, not evidence that the design is production-ready.

Weekly revisions

There are 26 numbered revision sources, each initially paired with five sequential concept sessions: R01 with S001–S005, through R26 with S126–S130. All 26 links remain under “Revision and transfer.” If you reorder concept study, adjust the week’s review set rather than assuming the original calendar mapping still holds.

Attempt the recall prompts, inspect the worked answers, run only the safe examples whose environment and permissions you understand, and record an unseen retest. Revision code demonstrates finite local behavior; it does not claim to reproduce optional cloud/GPU/framework runtimes. Reading or finishing a week is not mastery, and a route’s published status is not a proof of every deployment claim.

Corrective source notes

The Python 3.12 list-copy contract supports the exact protected shallow-copy example. Retrieval experiments (2006) and distributed-practice synthesis (2006) motivate delayed practice but do not establish this calendar or mastery deadline. Source counts, all 16 module ranges, 130 concept destinations, 26 revisions, ten lab destinations and read-only graph contracts were checked on 2026-10-08. This is full review of the hub’s navigation/teaching claims, not a new substantive audit of all destinations.

Timeline

A sample historical calendar runs from Monday 2026-07-27 through Saturday 2027-01-23: 26 Monday–Saturday study weeks, not an active commitment. At five 60-minute concepts plus one 90-minute revision each week, it has 156 events and 169 study hours, averaging 6.5 hours/week. The old “each session = 60 minutes” statement did not account for the 90-minute revisions.

The optional separate algorithm route adds 65 × 75 minutes = 81.25 hours, bringing the combined total to 221 events and 250.25 hours, or 9.625 hours/week. Alternate three- and two-algorithm-session weeks to fit that count; “every other day” over 26 weeks is a different schedule. Breaks, setup, extra practice and overruns are excluded. Extend the calendar instead of deleting objectives to preserve its end date. Nothing on this page creates calendar events or reminders.

Design principles

  1. Make prerequisites explicit. The route begins with setup but later subjects require accumulated skills; “zero background” is an entry option, not a promise that every later page is independently beginner-level.
  2. Use one coherent objective per study block where feasible. A session title can contain several mechanisms; split a difficult block and retain the remaining objectives rather than calling it mastered.
  3. Produce evidence. Derive, trace, implement or critique an example, with feedback and a changed-input check. An out-loud explanation alone does not prove implementation correctness.
  4. Name execution boundaries. Some lessons are conceptual, some have bounded local code and some discuss unexecuted services. Not every source is a runnable one-hour program; never invent a deployment to satisfy that slogan.
  5. Preserve the broad curriculum. The protected ten-lesson lab complements all 16 modules and the 65-lesson algorithm route. Revisit gaps with delayed tests instead of replacing the broad route with a convenient few exercises.

No blanket claim is made that old 36-topic, 48-session or 24-topic URLs redirect to equivalent lessons. Redirect equivalence and release acceptance require integration review; a link is equivalent only when its actual objectives are covered.

Pause / Recall / Apply

Can you explain it without the page?

Close the example. Reconstruct the core idea, then change one assumption. Mark complete when you’re ready; you can always undo it.

Stored in this browser only. No account, no sync. Clearing browser data removes your record.