Lessons from 6.115
May 26, 2026 | 1,252 words
It's my belief that most of your life merely waits for a narrow set of defining
experiences. At MIT, my defining experience was 6.115.
6.115 (now 6.206) is the course code for Professor Steven Leeb's "Microcomputer Project
Labratory". There is little public information about this legendary
class — a class Leeb has been teaching for over two decades — so I
figured a future student might appreciate another anecdote. But if you don't go
to MIT, perhaps you'll still appreciate some colorful commentary on engineering
below.
Drinking from the Firehose
6.115 is the only class in the past 3 years that has actually made me drink from the fire
hose.
The main reason for this
is that 6.115 — like true engineering — does minimal hand-holding. Outside of
basic circuits, computer architecture, and assembly programming knowledge, none
of this course's material is taught elsewhere at MIT. In that regard, 6.115
feels less like a class than it does a self-directed, free-form engineering
project. Only you can solve the horrendous and inexplicable fault in your
circuit, debug the 400 line assembly program, or figure out that, indeed, the
only reliable way to measure a
noisy voltage is in time-averaged mode on the scope.
Engineering is an endless onslaught of stupid errors, all of which we will
make in our travels on the road to mastery.
The Blackbird
The first lab endows you with a big black briefcase, amically referred to as the
"Blackbird." Inside this kit are 3 adjacent breadboards, an R31JP dev board,
and tons of peripheral test equipment (exposed pins, speakers, pots, LEDs, etc.)
The R31JP dev board is replete with an Intel 8051 8-bit microprocessor, 32KB ROM and 32KB
RAM, chips to allocate part of the memory to IO (MMIO), an RS-232 com port, and
various other ICs needed to compose a basic — yet capable — computer. The
first three quarters of the class are exclusively assembly, with the final
project freeing you to program in C on a PSoC 5LP (see my final project
Flopper).
The Labs
Without giving too much away, each lab is a new problem: "simple" tasks like
igniting a florescent lamp or playing music, to hairier challenges like
projecting laser Lissajous curves or controlling robotic arms. (One tool that just seems to work for all of this is the square wave
— of which you'll write the code to generate at least 7 times throughout the
class.) The course staff has prepared a lot of equipment for these labs; even
still, the task of interfacing and controlling the provided equipment is
formidable.
Sitting in the labs some evenings, I felt my mind expand. Your system will
contain at least 5 equally culpable and volatile components, ranging from the
code, the circuit, the ICs, the scope config, and the power supply. To debug
this complex system, you must
simultaneously reason about each these parts and carefully disentangle their
interactions until the underlying cause becomes clear.
These labs teach you to:
- Confidently read any datasheet
- Maintain a practical circuit-design framework
- Master the 8051 instruction set
- Internalize computer architecture fundamentals
- Confidently build low-power embedded systems alone
The atmosphere inside the lab is collaborative while you fight together with
your peers. But at the end of the day: everyone's got their own problems, so any
help exchanged is necessarily short-lived. For the most part, you're on your
own.
Leeb's Lessons
Another great draw of the class is Professor Leeb himself. By far the most
charming, entertaining, and well-prepared lecturer I've encountered at MIT, Leeb
gives you permission to call yourself an engineer. The lectures themselves are
both profound and engaging, filled with vivid analogies and
anthropomorphizations of our equipment (never before had I seen a computer as a
menagerie of squirrels, jets, Terminators, and wizards). But they are also rich with wisdom, two of whose central lessons I will distill here.
While it may sound like I'm speaking directly to you, I'm not. The words I write are for me.
Lesson 1: OODA
Above all else, 6.115 is a class in debugging. A central difficulty in this,
though, is that debugging cannot be taught. Rather, debugging (and, by
extension, engineering) is precisely the never-ending “whack-a-mole” attrition
of problems that invariably — and copiously — arise. In lecture, the best Leeb
could do was to preach the "OODA" process.
OODA stands for Observe, Orient, Decide and Apply. In brief, OODA is a more
principled way to think about debugging complex systems: one that selects
maximally informative actions to address the most probable barriers.
Intuitively, this is how any sort of debugging should be done.
The core challenge is that engineering, with its many challenges, is rarely
undertaken with rational repose. Rather, engineering is executed under
high-pressure timelines, amid competing demands and distractions, and in an
unavoidably emotional state. The frantic effort to make your system just
work
will lead you down a series of bad decisions until, without noticing it, you've dug
yourself into a much deeper trough than before. Debugging from this deep hole is at least twice as hard, though it could have been avoided entirely with a level head.
Debugging reminds you to let go of your ego: if you've really tried everything,
why is your system still broken? Don't try to fix what isn't likely the problem.
Question what you think you know. Start at the
smallest seed of knowledge you are certain of, and go from there.
This process
cannot be done without understanding your system. In the era of LLMs,
this is perhaps the most important principle to remember: it's never been
easier to build atop foundations you do not understand, accumulate tech debt,
frustration, and ultimately undermine yourself.
Lesson 2: Engineers help people
[ The founders and beneficiaries of MIT ] understood that the purpose of technology is to enhance human ability. And that the existence of good technology had given us — for the first time in history — the ability to think about improving our lives without directly taking away from someone else.[ Funding MIT ] is not simply an investment — if you'll permit me: it's a prayer. It's a prayer that there would be a place where people could gather together and use their minds to help stop U-boats and help free children from behind barbed wire, cure disease, and improve the human condition. This place was made, again and again, to educate fighters: people who would stand flatfooted in front of a problem, not complain, and solve it. That's why this place is here.— Steven Leeb, Apr 2026
As engineers, we find ourselves in the most fortunate period in human history. Never before has one person been able to have so much influence on the trajectory of our species. Never before has one person's passion (for technology) had the upside potential we have today.
We are so fortunate that something as fun, personally enriching, and endlessly
nuanced as technology can also improve the condition of others. You ought not
trivialize it.
If you're reading this, you can change the world. You can have
gigayear impact, and a good life,
too. Be stubborn, obsessed, and refuse to work on anything without this upside.
To MIT Students
If you're even remotely interested in EE, CS, or what engineering really feels
like — and you've been as lucky as me to arrive at MIT — take 6.115. Eat,
sleep, and breathe the class.
Fight to build. Build to win.