What to read

Most software today is built to be forgotten

Written in haste, layered with abstractions, then discarded with the next trend. We build like amnesiacs: few know how the systems beneath them truly work. Fewer care. The result is not progress, but erosion masked as innovation. Like a civilization building towers higher and higher while forgetting how to quarry stone.

Jonathan Blow warned us of this trajectory: a slow technological decline driven not by catastrophe, but by accumulated ignorance. As layers pile on, foundations are lost. One day, the lights will go out—not because no one tried to keep them on, but because no one remembered how.

There is another path.

We can choose to treat software not as a disposable product, but as a form of cultural expression. A craft whose goal is not speed or scale, but clarity, permanence, and meaning.

This is the path of Emacs, Vim, Unix, and many other libraries and systems built and maintained in C — that old, unsafe language. The very same language used to build and maintain most of the internet’s infrastructure. Systems some now call “legacy,” but which are, in truth, civilizational infrastructure.

People say JavaScript is the language of the internet.

It is not.

The true languages of the internet are plain old C and C++, the very languages no one wants to teach or learn anymore. Sorry to say, but JavaScript is just a rushed wrapper over decades of C and C++. It can do some cool, good-looking stuff, because the marvel that is a modern web browser; guess what, written in C and C++. But we can’t count on it to keep the edifice from falling apart.

Don’t get me wrong — we need those things too. A Ferrari isn’t a Ferrari without leather seats and polished interiors. But no one dreams of owning one because of the leather. They dream of the engine, the pristine mechanics, the architecture that makes performance possible, and the artisanship of a machine built by engineers and technicians who are also craftsmen.

These things have not survived in spite of their age. They have survided because some people took the time to develop rare and deliberate skills. They have survived because these people want to transcend their own lives by doing timeless artifacts.

To walk this path requires more than technical competence. It requires erudition.

Erudition is not mere knowledge—it is the discipline of memory. It is the refusal to discard what came before simply because it is old. It is what separates the craftsman from the technician. The former builds tools; the latter uses them.

This is not a call for nostalgia. It is a call for depth.

Edsger Dijkstra argued that software should be beautiful, that clarity and elegance are moral virtues in code. Richard Stallman, despite his politics, glimpsed something similar: software, if well written and liberated from arbitrary dependencies, becomes free from its creators. It becomes self-sufficient, a thing that exists on its own terms.

To write such software is not merely engineering. It is a form of authorship.

And yet, why bother?

Economics can’t fully explain open source. Eric Raymond got close. Yes, incentives matter, but the real motivation is harder to measure. It’s not just reputation or signaling. It’s something older, deeper. The pride of the artisan. The drive to leave something behind. The desire to see one's soul reflected in a functioning machine.

We don't need more developers. We need stewards of tradition. Programmers who see themselves as participants in a conversation older than their tools. Programmers who understand that code is not just meant to work, but to last.

On Education and the Cult of Utility

Our institutions are not preparing the next generation to build what endures. I know that very well, I'm a professor at a major university in Brazil. And truth be told, I'm probably more part of the problem than the solution.

Schools are increasingly pressured into “project-based,” “real-world,” “hands-on” pedagogies—buzzwords that too often mean building whatever solves the most immediate problem, then moving on. This is the educational branch of the same Silicon Valley rot: fail fast, fail often, ship it, forget it.

At the same time, theory-driven programs—those that ground students in algorithms, computation, and systems—are dismissed as outmoded. Why study SMTP when you can deploy a serverless app in five minutes? Why implement a shell when you can call one? Why understand when you can use?

This is a catastrophe disguised as relevance.

Real-world problems aren’t just the ones we face now—they are the ones we’ve already solved. The wheel, once invented, is worth studying. But we rarely ask students to reimplement anything that matters. How many have written a shell? A CLI email client? A toy compiler? A browser? An operating system? These are exercises not in nostalgia, but in transmission—how to pass down the thinking behind software that actually lasts.

Instead, we hand students tools as if they were gifts from God.

But God does not maintain software. That’s up to us.

But wait, Edil — what do you mean by us? Where’s the timeless code you’ve written yourself? You might ask me that. And it hits me hard. I truly envy some of the programmers I’ve worked with. When I watch them do their craft, I wish I were doing that too.

But I’ve also come to realize that, almost as important as having the artists working, is inspiring and guiding the next generation of artists. I believe I could be building good software. But I also believe I’m most valuable when I help build good people.

I hope I’m doing that well enough. But only time will tell. And I don’t care if nobody sees it. I’m trying to shape people in a tradition I believe leads to real progress, not just good-looking frontends. If two or three of them end up helping to build something truly foundational — something that lasts — that’s probably more than I could have done myself.

On AI and the Seduction of Vibe Coding

The recent obsession with large language models has amplified the very disease we aim to treat. It is now fashionable to "vibe code"; to prompt a machine, skim the output, and paste until it runs. It feels like programming. It looks like productivity. But it is neither.

Vibe coding is just the latest form of disposable software creation. It encourages the illusion of mastery while hollowing out the discipline itself. You are not becoming a better developer by prompting until it compiles. You are simply becoming a more efficient operator of a glorified autocomplete engine.

There is nothing wrong with using LLMs, when used with intentionality and craft. For the erudite programmer, these models are like sharpened chef’s knives: amazing tools for thought that can accelerate judgment, precision, and depth. But in unskilled hands, they do not produce better software. They produce more software. Worse software. Cheap, flimsy, mass-produced code—the Chinese plastic of the digital world.

And worst of all: we are deceiving ourselves. We confuse activity with learning. We conflate output with experience. We mistake convenience for growth.

Like junk food for the mind, we’re intoxicating ourselves with crap software. It fills you up, but it doesn’t nourish. And over time, it rots your taste, until you can’t even tell the difference between a fine wine and vinegar.

This is why we read. Not to memorize syntax, but to train our taste. Not to chase novelty, but to understand roots. Not to master tools, but to become worthy of building them.

Let others chase the ephemeral. We are here to build what endures.

Why I Care About This List

Because I remember, every single day, what it feels like to be lost in the noise. To want to become a great engineer, but not know where to look. To feel that something important is missing, some deeper foundation, and yet be handed only tools, frameworks, and deadlines. And to feel lonely (and a little afraid that I'm crazy) because no one around seems to feel the same.

This list is my attempt to push back against that. To offer a path. A tradition. Not a curriculum. Not a checklist. Just a thread you can pull — if you're ready to go deeper.

This is a way to start a conversation with the great minds who came before us. Because great people have always existed. Because brilliant thinkers lost sleep over the problems we now treat as trivial. Because they offered solutions in a time of scarcity, when computing was expensive, memory was counted in kilobytes, and mistakes had consequences. They had no resources to waste like we do now.

I’ve read every reference in this list — some of them many times. I’ve read far more than what’s here, but these are the books that made me think. These are the ones I wish I had started with, twenty years ago. No, these are the ones I wish I had read in spite of all others. I can’t go back in time. But maybe I can help someone else avoid the fast-food books and disposable references.

Learning is not a linear process. Other than GEB and SICP, I don’t think there’s a right order to begin digesting these works. Embrace the chaos. Read these books in any order. Study them while you work your day job. Keep your mind’s eyes sharp and open and over time, you’ll begin to see where the pieces connect, and how to create better artifacts. Not by doing it right the first time, but by iterating. By refining. By caring.

Finally, I care because I’ve seen what happens when a curious student finds the right book or the right questions at the right time. It changes everything. Sometimes, all someone needs is a door left slightly open, and a hint that there’s more on the other side.