Courses: Structured Paths Through What We Have Published

These are reading and building paths, not enrolled courses. There is no instructor, no schedule, no credential and nothing to sign up for. Each path sequences material we have already published, adds something to build at every stage, and tells you how to check your own work.

We are explicit about that because the word "course" usually implies a product. What is here is a route through a large amount of material, in an order that works, with the practice attached.

How to use a path#

Read the guide, then build the thing, then check it against the checklist. The order matters — reading three guides in a row feels productive and produces recognition rather than capability. Recognition is the feeling that you would know this if you saw it again. It disappears under a blank editor.

The build step is small on purpose. Something you can finish in an evening will actually get finished, and finishing is what converts reading into knowledge.

Path 1 — AI for engineers who have not shipped it yet#

For someone who writes software and now has to put a language model in front of users.

1. RAG — how to make a model answer from your own documents, and why this beats fine-tuning for most business problems. Build: index a folder of real documents, answer twenty questions, record the hit rate. Check with the RAG checklist.
2. Prompt engineering — the parts that survive contact with production.
3. AI agents — when an agent beats a workflow, and the tool/blast-radius discipline. Build: one agent with two tools, a hard spend cap, and a stopping condition. Fill in the agent specification before you write code.
4. AI Testing Center — testing software that gives a different answer every time. Build: a fixed task set and a pass rate you can re-run.

Finish when you can state your system's retrieval hit rate, its cost per answer, and what it does when it does not know. Most people who "know RAG" cannot answer the third.

Path 2 — From developer to someone trusted with production#

For engineers whose systems are now other people's dependency.

1. Software engineering — review, debt, working with legacy code.
2. Testing — what to test, and what coverage does not tell you.
3. DevOps — delivery, rollback, on-call. Build: take something you deploy by hand and write the deployment runbook for it, then have someone else deploy it using only that.
4. Docker and Linux — the runtime underneath.
5. Cyber security — the controls that remove the most risk.

The runbook exercise in step 3 is the one that teaches the most, because handing your process to somebody else exposes every assumption you did not know you had.

Path 3 — Delivery and governance#

For analysts, project managers and anyone who has to produce the documents.

1. Project Charter — authorisation and boundary.
2. BRD → FRD → SRS — business need to system behaviour to engineering contract.
3. RTM and UAT — proving what was asked for was built.
4. Risk Register and Change Management — keeping the boundary.
5. Agile, Scrum, Kanban — how the work actually moves.

Build: take a project you are on and write a one-page charter with three measurable success criteria and a baseline for each. The measurability is where it gets difficult, which is the point.

Path 4 — Cloud and infrastructure#

1. Cloud — the business case, honestly.
2. AWS — accounts, identity, cost.
3. Docker → Kubernetes — in that order, and only continue to Kubernetes if you can name the problem it solves for you.
4. Architecture — the decisions that are expensive to reverse.
5. Data engineering — pipelines that fail loudly.

How to tell whether you have learned it#

Three tests, in increasing order of honesty:

Explain it to someone who will interrupt. Reading produces fluent summaries; understanding survives "but why not just do X?"

Build it without the guide open. Not from memory of the syntax — the shape. If you cannot start without the reference, you have recognised the material rather than learned it.

Predict the failure. Before running it, say what will break and why. Then run it. Being wrong here is the most valuable minute in the whole path.

FAQ#

Are these real courses with instructors?#

No. They are structured paths through published material, with exercises. There is no enrolment, no schedule, no instructor and no credential. We are direct about this because "course" usually implies all four.

How long does a path take?#

Depends entirely on the build steps, which are where the time goes. Reading a path takes a few hours; working through it properly takes weeks of evenings. The reading is not the course.

Do I get a certificate?#

Not from us — we do not issue credentials, and one from an organisation you have not been assessed by would be worth nothing anyway. See Certifications for which industry certifications are actually worth the money.

What order should I do the paths in?#

Whichever matches the problem in front of you. Learning driven by a real task sticks; learning driven by a syllabus mostly does not. If nothing is pressing, path 2 is the most broadly useful.

I have no time to build things. Can I just read?#

You can, and you will retain a fraction of it. If time is genuinely short, cut the number of topics rather than the build step — one topic learned properly beats four recognised.

Is there anything to pay for?#

No. Everything referenced here is published on this site and free, with no sign-up. Where a paid external resource is genuinely better we say so and do not earn anything from it.

What if a path references something not written yet?#

Then it is not in the path. Every link here points to material that exists. If you find one that does not, it is a defect — the build fails on broken internal links, so it should not happen.

Related Articles#

Continue with Career Paths for role-based sequences, Exercises for short practice, Projects for portfolio builds, and Interview Questions when you are ready to be asked.

What else is coming for Courses