What the machine is doing

Why this task exists at all

Open any popular zero-to-job guide and you will find this month missing. Language, then data structures, then grind, then apply. It works, in the sense that people get hired, and then the bill arrives over the following years: engineers who cannot reason about why the recursive solution blew the stack, why the "faster" code is slower, why two variables seem to share a value. Ask self-taught engineers a few years in what they wish they had learned earlier and some version of "how the machine actually works" tops the list with embarrassing consistency.

The other ditch is overcorrection. jwasham fixed his gap by studying most of a CS degree's worth of architecture, assembly included, and his own retrospective says he over-prepared. This task takes the load-bearing third: enough to have a mechanical model of your running program, nothing that exists mainly to pass a sophomore exam.

Week one: watch it run

Concepts that are abstract in a textbook are obvious when you watch them happen, so this task starts in the visualizers, in a deliberate order, each one building on the last:

1. How computers work — the whole machine in one pass: CPU, memory, the fetch-decode-execute loop. The frame everything else hangs on.
2. The call stack — what calling a function physically does. After this, recursion stops being mystical and stack overflow becomes a sentence with a literal meaning.
3. Stack vs heap — the two places your data lives and why the distinction leaks into every language you will ever use.
4. How memory works — addresses, allocation, and what a variable actually names.
5. Source to machine — the journey from the text you wrote to instructions the CPU runs, which closes the loop the first walkthrough opened.

Budget a week, and go slowly on purpose: after each walkthrough, write three sentences from memory about what you saw. Those sentences are the start of this task's deliverable.

Weeks two and three: the hierarchy and the cycle, lite

Now the same material with more precision. Work through the first half of the computer architecture codex: the memory hierarchy and the instruction cycle. The two ideas to actually own:

• The memory hierarchy is a series of trade-offs, not a parts list. Registers, cache, RAM, disk: each level is bigger and slower than the one above by roughly an order of magnitude or more. Half of all performance conversations you will ever have are about keeping data high in this pyramid.
• The CPU is a fast, dumb loop. Fetch an instruction, decode it, execute it, repeat, billions of times a second. Every clever thing software does is compiled down to this loop. Holding that firmly is what makes "the computer is doing something mysterious" an unavailable thought.

Stop at "lite." Pipelining details, branch predictor internals, cache coherence protocols: real topics, not this month's topics. The second half of that codex will still be there when a job makes it relevant.

Week four: Big-O as something you watched happen

Big-O learned from a table of symbols produces people who can chant "n log n" and cannot say why their nested loop is slow. Learned this month, with the machine model fresh, it is just counting: how many times does the dumb loop have to go around as the input grows?

Read the growth-rate material in foundations, then run the Big-O race and watch the curves separate in real time. Race n² against n log n at a few input sizes and notice the moment the gap stops being academic. That image is what you will actually consult in interviews, long after the notation rules fade. Then connect it downward: an array scan is the loop running n times; the hash lookup you will meet properly in task 4 is the loop mostly not running at all. Big-O is not a topic, it is the machine model with a growth knob.

The deliverable: one page, no magic

One artifact gates this task. On paper, no references, explain what happens between typing python program.py and seeing output, down to "the CPU fetches instructions" granularity. The interpreter loads, your source is parsed and compiled to bytecode, the interpreter's loop walks it, functions push and pop stack frames, objects get allocated on the heap, and underneath everything the fetch-decode-execute cycle is grinding away. A page or so, in your own words, with no step that secretly means "and then magic."

What to skip, by name

Skipping needs to be a decision, not an accident, so here is the list. jwasham's own curriculum draws a line under which everything is marked optional, and experience says the line is right:

• Red-black tree rebalancing internals. Know that self-balancing trees exist and what they guarantee; task 4 covers the general concept. The rotation case analysis is reward-free at this stage.
• Fast Fourier transforms. Beautiful, and not on this road.
• Network flow algorithms. Max-flow shows up in competitive programming and almost nowhere in interviews at this level.
• Assembly fluency. You watched source become machine code in week one; that is the load-bearing part. Writing assembly is a hobby, a fine one, later.

The test for anything not listed: does it sharpen the model of your program running? If not, it can wait. The model is the deliverable, and the next task is where it starts paying rent.