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.
Read itprogrammingrewritesengineering
Paul Graham
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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →