Symptom Driven Learning
Desire, humiliation and the chaotic art of learning to program.
Programming is, in a sense, a way of making art and with time, one can do a great deal with nothing but imagination. I have been programming since the age of seven or eight, mostly as an amateur. Now, about a decade later, LLMs have upended the landscape. Whether that is for the greater good is not something I can judge yet.
Instead, I want to describe, in plain terms, how self-taught amateurs (like me and my friends) have navigated this space over the last decade. I came across Paul Graham’s ”Hackers and Painters” in 2017, and that essay, alongside Peter Naur’s ”Programming as Theory Building”, shaped how I think and how I work today.
I want to present what I call “Symptom Driven Learning”, which is a distant cousin of Constructionism (Seymour Papert’s Constructionism). It is the antithesis of curriculum based, linear learning, and it is not the same as a top down methodology either. Its three components are desire, humiliation, and embarrassment.
Desire is the starting material. For most people, it begins with wanting to build a game (it’s a near universal cause) or breaking something just for the sake of it. The high of playing god is what hooks most of us in the first place.
That desire leads directly into humiliation. For every step you take, the machine punishes you without mercy. Sometimes it’d be a syntax error; something works one moment and breaks the next. You fix one bug, and a second one appears somewhere you never touched (blast radius ugh). Hence, debugging becomes a part of the act of programming, not something that comes later.
When reality humbles you at every turn, desperation sets in -- and the situation, the cause, the effect, and the solution all become fixed in memory. I believe pain catalyzes strong memory. That’s why people who have been humiliated by a problem before can pattern match their way to a solution faster than someone just starting out. It becomes a reflex.
But there’s a limit to this model. Some obstacles are simply inherent to building anything, or simply called non trivial by nature. The symptoms they produce would be near universal. Borrowing the idea of skill trees from Justin Skycak’s blog, I’d call these the foundational spine of the tree. Topics like memory management, basic data structures, understanding how a program executes from the moment a machine powers on etc. are a part of the spine.
The next layer of topics is summoned by whatever domain you happen to be working in. If I were building something concurrent, like a large sand simulator, I would go learn multithreading. If I were writing a library meant to work across types, I would explore templates or generics. Someone can be a genuinely excellent engineer for years and never touch templates, simply because their career never demanded it of them.
Everything I’ve described so far is symptom driven. Things you want OR don’t understand, and are forced to learn in order to clear an obstacle. But, reality is fuzzy. Some things don’t have any symptoms in the first place!
This is the problem I face daily. How deep should I go into a topic once I’ve entered it? Which paths are not worth pursuing in a complex system? Which questions are false leads? Self discovery doesn’t help much here.
This is where embarrassment enters, as the final and hardest earned component. Humiliation is the machine punishing you or me directly; but embarrassment is discovering, usually from someone more experienced, that your reasoning was wrong all alone. In one of my failed attempts to contribute to LiteRT, I ran into several design decisions that made no sense to me. I still don’t fully understand why a certain abstraction was chosen when it didn’t seem necessary-- or perhaps it only seemed unnecessary to me. The walls in this territory are invisible until someone more experienced points them out. Judgment, unlike syntax, can’t be discovered through introspection alone. It has to be given to you, usually at the cost of your ego.
A few writers and pieces that shaped this thinking: