100 papers to understand software and computing

There is a familiar way to avoid reading a great paper: add it to an excellent list.

I opened Facundo Olano's software-papers collection and did what most of us do. I kept scrolling, recognized a few titles, opened too many tabs, and felt briefly educated without having read anything.

The collection deserves better. It currently spans 148 papers, from Bush and Turing to Dynamo, CRDTs, and transformers. Its twenty anchor topics already contain the bones of a serious software education.

This guide turns that generous archive into a place to begin: one hundred papers across twenty connected themes.

It is not everything a software engineer could read. It is enough to build a working map of the ideas beneath programming, databases, networks, interfaces, distributed systems, and machine learning.

A list is not a curriculum

The source repository is arranged with care. Early programming leads into information theory and algorithms. Networking appears before distributed systems. Operations follows internet-scale storage.

That order matters. Lamport's clocks land differently after packet networks. Dynamo is easier to judge after transactions, end-to-end arguments, and consensus.

Still, a repository has no obvious entrance. Every related paper looks equally urgent, which makes it difficult for a new reader to choose the first useful thread.

This reading map keeps the source order but adds a question to each theme. A theme is not simply five PDFs. It is one conversation carried across five papers.

In the software-design theme, for example, Liskov and Parnas are not five independent history lessons. They are an argument about where knowledge should live when a system must change.

What made the cut

Olano's own selection criteria are refreshingly practical: favor readable, self-contained work, keep most picks reasonably short, make them freely available, and prefer ideas that reached engineering practice.

This map inherits those instincts. Each theme starts with the repository's anchor paper, then adds four companions that sharpen, challenge, or operationalize it.

Two small adjustments make the count land at exactly one hundred. Bloom's filter paper joins information theory, where its tolerance for error makes intuitive sense.

“As We May Think” moves beside web search and information retrieval. Bush's imagined trails of association become more useful there than as a museum piece in the interface section.

This is a reading route, not a new canon. The credit for finding and organizing the archive belongs to its maintainer and contributors. Every item below opens the original paper or the source mirror.

Do not read it like a checklist

One hundred papers can become another intimidating number. There is no deadline here and no prize for reading them in order without stopping.

Start with the theme closest to the technology you want to understand. Read its anchor paper carefully, then use the four companions to see where the idea came from and what it later changed.

Some papers will take an afternoon. FLP, type polymorphism, and the cryptography papers do not become easy because they appear in a starter collection.

The check mark in the tracker means you completed a deliberate first pass and wrote down the paper's claim. It does not mean you could rederive the result at a whiteboard.

That distinction is the difference between a survey and theatre. The collection builds breadth. It also tells you which ten or fifteen papers deserve a much slower second reading.

Use more than one pass

S. Keshav's short paper How to Read a Paper describes three passes that grow from a bird's-eye view to a careful reading and, finally, an attempt to reconstruct the work.

The reading map borrows that shape, but it does not demand the third pass for every paper.

1. First pass: read the title, abstract, introduction, headings, conclusion, and references. Name the problem, claim, and context.
2. Second pass: inspect the figures, system model, examples, and evaluation. Mark the first step you cannot explain.
3. Third pass: reconstruct the argument, implementation, or proof. Reserve this for the anchor paper or a result that changes how you think.

Do not start at page one and treat every sentence as equally important. Papers are arguments with structure. Find the structure before spending attention on the machinery inside it.

The method also gives you permission to stop. A first pass may reveal that a paper is a historical waypoint, not a current priority. Record why and move on.

Leave evidence that you read it

A highlighted PDF is not much use six months later. After each paper, write four lines in your own words.

• Claim: what does the paper say is newly possible or newly understood?
• Mechanism: what is the smallest idea doing the real work?
• Cost: which assumption, failure mode, or tradeoff buys the result?
• Connection: which earlier paper does this revise, reject, or make practical?

Keep the note short enough that you cannot hide behind summary. If you need two pages to state the mechanism, you probably have not found it yet.

For a paper worth keeping, add one live example from your own work. A retry loop, schema migration, queue incident, or confusing interface is better evidence than another copied definition.

The sequence is the lesson

The first five themes ask what programming, information, algorithms, and modularity are. They give you a vocabulary for the rest of the collection.

The next five move inside programs and machines: paradigms, compilers, software projects, concurrency, and operating systems.

The third group widens the boundary. Data, packets, cryptography, distributed ordering, and human use all force a system to negotiate with something outside one process.

The final five themes show those ideas under scale: web search, cluster storage, operations, decentralized coordination, and machine learning.

Reading chronologically inside each topic helps too. You see vocabulary being invented, then inherited so completely that later authors no longer need to defend it.

Old papers are useful in a specific way

A 1968 paper is not valuable because old computing was purer. It is valuable because the author often had to name a problem that modern tooling has made invisible.

Dijkstra has to explain why hierarchy helps verify an operating system. Saltzer, Reed, and Clark have to argue where a guarantee belongs. Gray has to turn recurring failures into a model.

Those papers expose design choices before they hardened into defaults. That makes them unusually good material for engineers who need to decide when a default no longer fits.

They are also products of their time. Hardware assumptions, benchmark sizes, language, and social context may be dated. Historical importance is not the same as present-day authority.

Read with respect, not obedience. The useful question is not “Was the author right forever?” It is “What problem did this idea make easier to see?”

When a paper goes badly

Do not compensate for one hard paper by skimming the next four faster. Finish the first pass, mark the obstruction, and return when you have the missing context.

Use the theme's lens to decide what can wait. In the consensus group, you need the system model and the boundary of the result before you need to reproduce every proof.

If a link is blocked by a publisher or an old university mirror, search the exact title and author before substituting a summary. The paper remains the source; mirrors are only delivery paths.

For a slower paper habit, Fanout Daily gives one work at a time. For systems papers, the system design archive connects original ideas to concrete architecture decisions.

Finish with judgment, not trivia

After working through the collection, the useful outcome is not a hundred memorized author-year pairs.

You should be quicker to notice when a local optimization breaks an end-to-end guarantee, when a database tradeoff is being described as a universal law, or when an interface quietly transfers work to its user.

You should also have a personal shortlist: the papers you want to implement, argue with, or teach. That shortlist will be smaller than one hundred and more valuable.

The tracker below keeps progress in this browser only. Pick a theme, open its anchor paper, and leave four lines of evidence before you mark it read.