5 essays written decades ago that are more relevant than anything published this week
Most content published about software engineering has a half-life measured in months. Frameworks change. Tools change. Best practices get revised. If you read something from five years ago about the right way to deploy a frontend, half of it is already wrong.
But there is another category of writing -- rarer, slower, harder to find -- where the opposite is true. These pieces get more relevant as time passes, because they are about things that do not change: how complexity accumulates, how systems fail, how humans reason about programs.
Here are five that belong in that category.
1. "On the Criteria to Be Used in Decomposing Systems" -- David Parnas (1972)
Parnas wrote this in 1972. It is about how to split a system into modules -- a question every programmer answers every day.
His argument, which remains underappreciated: the right way to decompose a system is not by steps or phases, but by the decisions most likely to change. Each module should hide a design decision. The interface should reveal as little as possible about the implementation.
This is information hiding. We call it encapsulation now, or separation of concerns, or many other things. The vocabulary has changed. The problem has not. Most software systems today violate this principle in the same ways people violated it in 1972.
2. "The Mythical Man-Month" -- Fred Brooks (1975)
"Adding manpower to a late software project makes it later." This line has been repeated so many times that people sometimes treat it as folk wisdom rather than an argued position.
Brooks argued it carefully, from first principles: new people take time to onboard, create communication overhead, and subdivide work in ways that create more interfaces, not fewer. The book is full of insights that feel obvious in retrospect and apparently still surprise every generation of project managers.
3. "Programming as Theory Building" -- Peter Naur (1985)
This is the essay that most changes how you think about what programming actually is.
Naur's argument: a program is not the artifact. The program is the theory that the programmer holds in their head -- the understanding of the problem, the rationale for each decision, the model of how the parts relate. The source code is a byproduct of that theory.
The implication is severe: when the people who built a system leave, you lose the theory. The code remains, but the understanding does not transfer automatically. This is why rewrites from scratch often produce worse results than maintaining the original, and why documentation alone is never sufficient.
4. "Teach Yourself Programming in Ten Years" -- Peter Norvig (1998)
Written as a direct response to books titled "Learn Python in 24 Hours," this essay is about the actual pace of expertise development.
Norvig draws on research showing that deep expertise in any complex domain takes approximately ten years of deliberate practice. The piece has held up because the pressure it was responding to -- the promise of fast mastery -- has only intensified.
Everything that is now sold as an accelerated path to competence is still what Norvig was writing against. The answer has not changed either.
5. "Reflections on Trusting Trust" -- Ken Thompson (1984)
Thompson's Turing Award lecture is one of the strangest and most important pieces of writing about software security ever published.
He demonstrates that you cannot fully trust software you did not write yourself -- and then extends this to compilers, to the tools that build the tools, to the entire stack beneath the code you see. The essay demonstrates its own point in a way that is genuinely unsettling.
More broadly, it is about the nature of trust in layered systems: how confidence propagates, how it can be violated invisibly, and how hard it is to verify the things you rely on most.
The value of reading these is not nostalgia. It is that they were written by people trying to understand hard problems, before the field had developed comfortable answers. That kind of writing teaches differently than writing that synthesizes what is already known.
Read slowly. Return to them.