I designed my own four-year bachelor — and I'm studying it in public

By Seyed Masoud Hosseini · Sep 15, 2026 · Learning

Thirty-six university courses, eight terms, one exam and one real artifact per course. Why a working software engineer built a degree out of free lectures, how the whole system runs, and how you can use it.

Today is day one of a degree that no university will ever hand me.

It has thirty-six courses spread over eight terms. It starts in Fall 2026 and ends with a senior project in the summer of 2030. Every lecture comes from a real university or a world-class teacher: Stanford, MIT, Yale, Harvard, Berkeley, Oxford, ETH Zurich, CMU, Princeton, Andrej Karpathy. Every course closes with an exam and something I build. And every hour of it happens in public, on this site.

This post explains why I did it, how the system works week to week, and how you can use it — whether you want to follow along, borrow the curriculum, or build your own.

Why a software engineer needs a bachelor he designs himself

I've spent my career building backend systems, infrastructure and the teams that run them. That work taught me a lot, but it taught me unevenly. Production work rewards depth in whatever is on fire this quarter. It rarely gives you a reason to learn how a CPU pipeline actually works, why a proof of an estimator is unbiased, or what Kant would say about the product decision you made last week.

Over time I noticed three gaps that kept costing me:

1. The foundations under the stack. I can ship a distributed service, but the layers below it — computer architecture, circuits, compilers, the maths inside machine learning — were things I knew about rather than things I knew.
2. The field that is rewriting everything. AI is no longer a side topic for engineers. Using models is easy; understanding them well enough to build, debug and lead teams around them is not.
3. The human side of leading. Managing engineers is a craft of judgment: psychology, ethics, economics, writing clearly. None of that is in the documentation.

A traditional degree would fix some of this, at the cost of years of fixed schedules and a syllabus designed for someone else. Random online courses fix nothing, because without structure they end the way most of us know: three lectures in, then nothing.

So I took the part of university that actually works — structure, breadth, deadlines and finished work — and dropped the parts that don't fit a working engineer.

The model: 36 courses, borrowed from Yale

A Yale bachelor's degree is built from thirty-six course credits. That number is a good constraint. It is large enough to force real breadth and small enough that each course has to earn its place.

I spread the thirty-six courses over four years and eight terms, just like a regular degree:

• Fall terms run from mid-September to the end of January.
• Spring terms run from February to the end of May.
• Summers are free, except the last one, which is reserved for the senior project (June to August 2030).

Each term holds four or five courses. That sounds like a lot next to a full-time job, and it is — which is why the load is balanced so a heavy technical course always sits next to a lighter reading-and-thinking one.

Ten areas, on purpose

The courses are spread across ten areas. The mix is the whole point:

• AI — from building neural networks from scratch with Andrej Karpathy, through Stanford's CS229, CS231n, CS224N and CS336, to deep reinforcement learning, ML systems, ML compilation and LLM agents.
• Software — MIT's performance engineering, algorithms, computer security and distributed systems.
• Hardware — digital design and computer architecture from ETH Zurich, FPGA and Verilog, circuits and electronics from MIT, and building a 6502 computer on a breadboard with Ben Eater.
• Crypto — cryptography, Bitcoin, blockchain and money, and zero-knowledge proofs.
• Math — probability with MIT's John Tsitsiklis and matrix methods with Gilbert Strang.
• Philosophy — Harvard's Justice, Oxford's General Philosophy, Yale's Death and Moral Foundations of Politics.
• Psychology — Paul Bloom's introduction to psychology, Robert Sapolsky's Human Behavioral Biology, and MIT's The Human Brain.
• Management — How to Start a Startup, MIT's New Enterprises.
• Economics — Yale's Game Theory and Robert Shiller's Financial Markets.
• Writing — Larry McEnerney's The Craft of Writing Effectively, paired with a weekly essay.

The technical areas deepen the engineering. The rest sharpen the judgment that leading engineers depends on. I don't think either half is enough on its own.

The goal isn't a certificate. It's to be the kind of engineer who understands the whole stack — from transistors to teams.

How a course actually works

Every course follows the same loop, so the system never depends on motivation.

1. Watch the lectures, in order

Each course is tied to its official lecture playlist on YouTube, from the university or teacher who made it. On the course page you get the full list of lectures, and each lecture has its own page with the video embedded, its chapters, and previous and next links. No hunting through search results, no reposted copies.

2. Read the study guide first

Every lecture page has a study guide: what the lecture covers, the key ideas, a walkthrough with timestamps that jump the player to the right moment, what to review before watching, and questions to check your understanding afterwards.

These guides were drafted with AI from the lecture transcripts, and each one says so clearly until I have reviewed it. They are a map, not a replacement for the lecture. Reading the map first means I watch actively instead of passively.

3. Log every study session

After each session I write a short log entry: the date, the course, the hours, what I did, what I learned and the questions still open. It takes two minutes, and a small command scaffolds the file for me:

npm run bachelor:log -- c01 2.5 "Built micrograd"

Those entries are the heartbeat of the whole project. They feed the dashboard, the course pages, the full study log and an RSS feed.

4. Capture ideas as they appear

Studying across ten areas produces strange, useful collisions — a game-theory lecture that explains a team dynamic, a hardware course that suggests a tool. Those go into an ideas list, each linked to the courses it came from and tagged as a seed, something I'm exploring, building or have shipped.

5. Finish with an exam and an artifact

A course is not done when the last video ends. It's done when two things exist:

• An exam score. Most of these courses publish past exams or problem sets. I sit one under exam conditions and record the result.
• An artifact — something real built with what the course taught: code, a hardware build, a write-up, a small tool. Building it is where the ideas stop being familiar and start being usable. The artifact is linked from the course page.

Watching is easy to fake, especially to yourself. An exam and an artifact are not.

6. The transcript

Scores, grades and status for all thirty-six courses roll up into a transcript you can view on the site or download as a CSV. It's the same document a university would give you, except every line is backed by the log entries, notes and artifacts that produced it.

Why do it in public

I could keep all of this in a private notebook. I chose not to, for three reasons.

Commitment. A dashboard that shows the current term, the week, hours logged and courses completed turns a vague intention into a schedule I have to face every time I open it. Writing the plan down publicly is how I commit to it.

An honest record. Memory flatters. Months from now I will believe I understood a course better than I did. A dated log of the hours, the questions I got stuck on, the exam results and the things I built is the only reliable way to see what I actually learned — and where I need to go back.

Usefulness to others. The curriculum, the lecture pages and the study guides are free to everyone. If a single person uses them to start their own path, the project has already paid for itself.

How the system is built

The engineer in me couldn't resist building this properly, and the design choices are part of the method.

• Everything is a plain file. The program, the courses, every log entry, every idea and every study guide live as JSON and Markdown in the site's repository. Editing the degree means editing a file and pushing a commit. No database, no admin panel, nothing to break.
• Nothing is hardcoded. Progress, the current term, "now studying", hours and the transcript are all computed from those files and today's date. Mark a course completed and every page updates on the next deploy.
• Real pages for every lecture. The build generates a page for the program, each course, the log, ideas, transcript and all 858 lectures, each with its own title, description and structured data, so search engines can find them.
• Checked on every change. A validator rejects a course with a bad status or a log entry pointing at a course that doesn't exist, and tests guard the progress maths.

It's the same discipline I'd want in any production system: simple inputs, derived outputs, and checks that fail loudly.

How you can use it

You don't need to care about my progress to get value from this.

• Follow a single course. Open any course on the bachelor page, start at lecture one, and use the study guides as you go.
• Borrow the curriculum. The thirty-six-course plan is a reasonably balanced path for an engineer who wants AI, systems and hardware depth plus the humanities that make you better at work. Take it whole or swap courses for your own goals.
• Use the lecture pages as a study companion. Timestamped walkthroughs and self-check questions make long university lectures much easier to get through and to review later.
• Watch the experiment. The study log and RSS feed show what four years of structured, public learning looks like — including the weeks that go badly.
• Build your own. The approach is simple enough to copy: pick a credit model, choose courses across areas, require an exam and an artifact, log every session, and publish it.

What I expect to be hard

I'd rather write this down now than pretend later.

Consistency next to a demanding job will be the real test, not any single course. Some courses — computer architecture, deep reinforcement learning, distributed systems — will take far longer than their lecture hours suggest. Some lecture editions will age before I reach them, and I'll update them. And an exam without a professor is only as rigorous as the person sitting it — so I hold myself to the published conditions and time limits, and treat a low score as a reason to go back, not something to hide.

Day one

The first term starts today with neural networks from scratch, parallel computing with CUDA, Stanford's machine learning course, writing effectively, and Harvard's Justice. The first log entry is already up.

If you want to follow along, the whole degree lives at masoud.me/bachelor. If you start your own version, send me a note at me@masoud.me — I'd love to see what you put in your thirty-six.