Hackers and Painters
Graham's claim is that hackers and painters are the same kind of mind: makers who think by doing rather than engineers proving theorems. Read it and you start describing your own work differently.
Read itMore in Software Craft
EssaySoftware Craft2000
Things You Should Never Do, Part I
Joel Spolsky
Spolsky's case against throwing out the codebase and starting fresh, written in 2000 and somehow still news to every team that tries it. The ugly code you want to burn is full of bug fixes you've already forgotten making.
view similar →EssaySoftware Craft1972
The Humble Programmer
E.W. Dijkstra
Dijkstra's Turing lecture, arguing that our real job is taming a complexity we're not clever enough to hold in our heads. Fifty years on, the humility he asks for is still in short supply.
view similar →PaperSoftware Craft2007
What Every Programmer Should Know About Memory
Ulrich Drepper
Long, technical, and worth every page: Drepper walks the whole memory hierarchy like someone who genuinely wants you to understand caches, not just fear them. Still the reference.
view similar →EssaySoftware Craft2012
The 6502 Overflow Flag Explained
Ken Shirriff
Shirriff photographed a 6502 chip and traced the actual transistors to explain one status flag. Engineering as archaeology, done with slightly unreasonable care.
view similar →EssaySoftware Craft2002
The Law of Leaky Abstractions
Joel Spolsky
Spolsky's law: every abstraction that saves you effort leaks the messy reality underneath at the worst possible moment. Once it's named, you see it in every framework, ORM, and flaky network call you'll ever touch.
view similar →EssaySoftware Craft1997
The Cathedral and the Bazaar
Eric S. Raymond
Raymond watched open source actually work and tried to explain why a noisy bazaar of contributors could out-build a cathedral of careful planners. Agree or not, you're reading someone naming a phenomenon while it's still happening.
view similar →PaperSoftware Craft1985
Programming as Theory Building
Peter Naur
Naur's claim is that a program is really a theory living in the heads of the people who built it, and the code is only its residue. It explains why a codebase goes senile the moment that team scatters, source perfectly intact.
view similar →PaperSoftware Craft1968
How Do Committees Invent?
Melvin E. Conway
The short paper behind Conway's Law: you ship your org chart whether you mean to or not. Sixty years later, teams keep rediscovering that their software has the shape of their meetings.
view similar →EssaySoftware Craft1991
The Rise of Worse Is Better
Richard P. Gabriel
Gabriel's uncomfortable account of why the simple, half-right thing spreads faster than the carefully correct thing. He's describing evolutionary pressure, not handing out advice, which is exactly why it stings.
view similar →PaperSoftware Craft1974
The UNIX Time-Sharing System
Dennis M. Ritchie & Ken Thompson
The paper that introduced Unix, written by the two people who built it and plainly enjoying how much they'd managed to leave out. A masterclass in what simplicity buys you, straight from the source.
view similar →BookSoftware Craft1971
The Psychology of Computer Programming
Gerald M. Weinberg
Weinberg looked at programmers as people — ego, fear, the dynamics of a team — back when the field pretended code came from machines. Half a century on, the human bottlenecks he describes haven't moved an inch.
view similar →PaperSoftware Craft1986
No Silver Bullet
Frederick P. Brooks Jr.
Brooks separates the complexity that's essential to a problem from the kind that's just our tools getting in the way, then argues no single trick will ever kill the first. The most quietly disappointing — and durable — essay in software.
view similar →PaperSoftware Craft1974
Computer Programming as an Art
Donald E. Knuth
Knuth's Turing lecture, making the case that programs can be beautiful and that caring about that is not a distraction from the engineering. From the person who then spent fifty years proving it.
view similar →EssaySoftware Craft1984
Literate Programming
Donald E. Knuth
Knuth's proposal to write programs for human readers first and the compiler second, weaving prose and code together. Most software still treats the reader as an afterthought, which is precisely why it reads fresh.
view similar →