On Reading Code

What Alan Moore can teach us about becoming better at our craft.

In 2025, we’ve been focused on speculating about AI, learning how to work with agents, and adapting to an ever-changing landscape. But in the last newsletter for the year, I want to turn your attention to what’s actually important - building good software and how we go about it.

Dr. Manhattan on Mars

Growing up in Eastern Europe, the superhero culture was limited to mainstream characters. No one was translating comic books at the time, and they were nigh impossible to find, so you'd better hope you catch that early morning Spider-Man episode that airs when you’re getting ready for school.

When I played my pirated copy of Watchmen during the superhero movie boom, I expected a story that followed the formula I’d seen many times over. A villainous entrance by the bad guy, an initial defeat for the flawless heroes, only for them to return stronger and win in the end.

Watchmen’s nothing like this.

It gives a gritty twist to the superhero genre, and it was the first time I saw “superheroes” portrayed as imperfect beings with human flaws, needs, and personal agendas.

But Alan Moore didn’t create this story by accident.

Read Everything

Moore broke the formula because he knew it better than anyone else. He reinvented the superhero not because he ignored the genre’s history, but because he understood it well enough to twist it into something new.

And that was Alan Moore’s advice to future writers - read everything. Read the classics, poetry, philosophy, pulp, comics, newspapers, and obscure esoteric texts. Read good books, but read bad ones as well.

The bad ones, especially, are instrumental in forming your taste in writing.

“Read terrible books as well, because they can be more inspiring than the good books… By analyzing why they are doing so badly, this will immensely help your own style. You’ll find out all of the mistakes not to make.”

— Alan Moore

Writers read hundreds of books before they try to write their own.

We, as developers, on the other hand, take the equivalent of a grammar course and set off to write “War and Peace”. Imagine writers not reading the classics. Not pushing through “Moby Dick”, nor suffering with “Crime and Punishment”.

Nothing great will come out of such a writer. At most, a superhero story that follows the formula I outlined in the beginning.

Programming is More Art Than Science

Paul Graham has this great essay called Hackers and Painters in which he argues that programming is closer to creative disciplines than to traditional engineering because our work is driven by taste, iteration, and intuition, not rigid processes.

Programmers refuse to accept that their work can be art, and artists struggle to acknowledge that their work is applied mathematics.

But if you read the essay and it manages to convince you even in the slightest, then we should take Alan Moore’s advice seriously and treat our improvement in this craft just like writers do.

“I don’t think there’s really any difference between art - or writing, or music - and magic. And I particularly draw the link between magic and writing. I think that they are profoundly connected.”

— Alan Moore

Good grammar is a prerequisite, but there’s more to writing a good story - plot, characters, voice. The same way, knowing a programming language is non-negotiable, but there’s more to building software - architecture, scale, maintainability.

Like artists, we build our intuition about good software through iteration, working on real, lived-in software, not isolated code snippets.

When I started writing, people told me I needed to read Camus, Dostoevsky, Chekhov, and Steinbeck, but no one told me the codebases I should read to see how people build.

Building Intuition

Most developers build their taste for good software naturally as they change companies - they see which patterns work and which don’t.

That’s why I still think years of experience somewhat matter.

The more time you spend in the industry, the more projects you get to see. You learn how their domains are modeled in the codebase, the challenges, and how real software looks.

You will see terrible failures and spaghettified codebases, but they, too, are important. Like pulp fiction and airport books whose endings you know before you open up the first page, the negative data points are just as valuable.

“There is no substitute for practical experience, and if you want to write about people you ought to put down that comic book and go out and meet some of them rather than studying the way that Stan Lee or Chris Claremont depict people.”

— Alan Moore

I find that developers who quickly become good at building software have unintentionally found a way to fast-track this learning experience and build their intuition.

Working on their own side projects, taking up freelance gigs, and contributing to open source - all these expose them to more domains, more collaboration problems, more obscure edge cases.

Reading Open Source

I had no trouble doing my 9-5, then coding until the AMs when I was 22, but now, with a family and responsibilities outside of work, I find it difficult to follow the same schedule.

I can’t continue building things in my spare time or moonlighting in a second company anymore. It’s too draining, and I’ve been dancing with burnout way too much.

But open source is a goldmine for good reading material, and I can enjoy going through projects like a good book. I don’t have to study them like a textbook, analyze them, or even run them. I can take in the codebase like I’d read a book in the morning.

Open source seemed daunting to me.

I felt unworthy of even reading it. Code that sits out there in the open to be reviewed by everyone must surely be complex and written with extreme care.

Yes, trying to read React’s codebase without prior knowledge will probably leave you more confused than enriched.

But think about all the small libraries and tools you use daily, the joints that keep the whole thing together.

I find that they’re very much worth reading.

Reading Lodash

The first open source library I gathered the courage to explore beyond the README was Lodash - a collection of utility functions that were invaluable in the past when the JS standard library was poorer.

I started with it because I hoped it would be simpler, but I didn’t expect that the entire library would be kept in a single JavaScript file that’s 17K lines long.

That’s a library with 80+ million downloads per week.

They don’t publish this enormous file, though. It will stretch out the network cable it travels through. The complexity in Lodash is in its build process. They have a CLI that mangles the file into different formats and builds.

In the industry, such a file would be considered a massive anti-pattern, and I never would’ve seen working software implemented this way.

Did I like it? No.

But I learned that what you deliver doesn’t have to be the same as the thing you write.

Reading React-Query

Some time later, I did the same with react-query, a popular data fetching library in the React ecosystem.

I wasn’t sure where to start with a large, complex, unfamiliar codebase, so I did what I do at work - I followed one of its public-facing APIs.

I found where their most widely used function was exported, and I followed its implementation all the way down, command-clicking through functions and layers until I reached the bottom.

And I found that it actually used classes underneath.

Yes, classes.

In a JavaScript library used on the front-end. Lightweight functional programming has been dominating the ecosystem for years, and object-oriented code was the last thing I expected.

Did I start using classes in my React projects? I didn’t.

But reading this codebase taught me that you can work with data outside of the React component lifecycle.

The Software Engineer’s Vocabulary

This is not the kind of knowledge that will help you pass FAANG interviews. It’s the kind that will help you build actual software.

If you don’t read, you won’t have a vocabulary to write with, and if you’re not studying real software, you won’t learn patterns to build with.

Engineering blogs are a great source of information, but I find them to be too curated. Every sterile, over-engineered REST API that has more boilerplate than domain logic has been inspired by a blog post.

Wins and breakthroughs are interesting to read about, but real software sometimes has 17K lines-long JS files that no one is eager to write about.

We study theoretical best-case scenarios and then expect to build actual production software based on ideas discussed in a vacuum. This is unrealistic. Software failures are most often a failure of imagination and our inability to handle complexity, and this imagination gets fostered as you read more and more.

Getting familiar with new ideas only when you change companies is the same as only reading a book every few years.

We need to constantly study existing projects until we understand the shape of quality and develop a taste for good software.

Because that taste is what lasts.