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.
view similar →Software Craft
Things You Should Never Do, Part I
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 →The Humble Programmer
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 →What Every Programmer Should Know About Memory
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 →The 6502 Overflow Flag Explained
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 →The Law of Leaky Abstractions
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 →The Cathedral and the Bazaar
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 →Programming as Theory Building
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 →How Do Committees Invent?
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 →The Rise of Worse Is Better
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 →The UNIX Time-Sharing System
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 →The Psychology of Computer Programming
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 →No Silver Bullet
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 →Computer Programming as an Art
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 →Literate Programming
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 →Nothing here yet. Try another search or clear the filter.