Going Down the Stack (Part 1: The Plan)

I’m climbing down to the metal. This is my plan for getting there.

I’m a backend engineer. I’ve built services, designed APIs, wrangled databases, and shipped systems that real people use. I’m comfortable up at the top of the stack. Lately, that comfort has started to bother me.

Because the truth is, there’s a whole world underneath what I do that I’ve never understood. My program allocates memory, and I couldn’t tell you what actually happens. It crashes, and I take the operating system’s protection on faith. I use pointers without knowing what one is underneath the abstraction. Somewhere between the code I write and electrons doing useful work, there’s a translation I’ve never watched happen. I’ve spent my career standing on top of these layers without ever looking down.

This series is me looking down.

What this is

Down the Stack is a learning log. I’m going to teach myself low-level computing in public, starting from where I am (a high-level developer who’s never seriously written C) and descending, layer by layer, toward the hardware. I’ll write up what I learn as I learn it.

I want to be honest about what this is not. It’s not an authoritative tutorial from someone who already mastered this material. I’m a beginner at this layer. I’ll get things wrong, hit bugs I don’t understand, and occasionally discover that something I thought I understood I only half-knew. I’m going to write all of that down too, because the confusion is the interesting part. The post I most wish existed is usually the one written by someone who just figured the thing out and still remembers what was confusing about it.

Why bother

A few reasons. The honest one: I want to be the kind of engineer who understands the machine all the way down, not just the framework on top of it. The practical one: that understanding makes you better at everything above it, from performance to debugging to reasoning about what your code actually costs. And the selfish one: writing about something is the fastest way I know to find the holes in my own understanding. If I can’t explain how virtual memory works in a blog post, I don’t understand it yet. This series will keep me honest.

The plan

Roughly, here’s the descent I’m planning, though I expect it to shift as I go:

• C, properly. Not “hello world” C: pointers, manual memory, how a struct sits in memory, the standard library, the compile-and-link model. The language the entire low-level world is written in.
• The machine. How code becomes assembly, how the stack works, what the CPU is doing. (I’ll be working through Computer Systems: A Programmer’s Perspective here. It’s the bridge from “I write services” to “I understand the machine.”)
• The operating system. Processes, virtual memory, system calls, scheduling: how the OS creates the comfortable illusion I’ve been living inside. I’m planning to study and modify a small teaching OS to learn this by doing.
• The kernel and below. Kernel modules, maybe eBPF, maybe a device driver: getting my hands on the layer where software meets hardware.

Each post will go a little further down than the last. The plan is loose on purpose. Part of what I’m curious about is where this pulls me once I’m actually in it.

If you’ve ever felt the same itch, comfortable at the top and curious about the bottom, follow along. First real stop: C, and everything I never understood about pointers.

Let’s go down.