resources
constantly updated as i find more good stuff
papers worth reading
the unix time sharing system
ritchie & thompson, 1974
the paper that started it all. how unix was designed and why those decisions still matter today.
read paper →communicating sequential processes
hoare, 1978
the theoretical foundation for go's concurrency model. essential reading for understanding channels.
read paper →can programming be liberated from the von neumann style?
backus, 1977
why functional programming matters. the turing award lecture that changed how we think about computation.
read paper →end to end arguments in system design
saltzer, reed, clark, 1984
why complexity belongs at the edges, not in the middle. applies to everything from networks to apis.
read paper →worse is better
gabriel, 1991
why simple, imperfect solutions often win over complex, perfect ones. explains unix's success.
read paper →hints for computer system design
lampson, 1983
practical wisdom from xerox parc. how to build systems that actually work.
read paper →recursive functions of symbolic expressions
mccarthy, 1960
the paper that invented lisp. shows how powerful computation can emerge from simple primitives. functional programming done right.
read paper →on the criteria to be used in decomposing systems into modules
parnas, 1972
how to actually structure code. spoiler: information hiding matters more than whatever oop is trying to do.
read paper →why functional programming matters
hughes, 1989
the best argument for functional programming ever written. modular design through higher order functions and lazy evaluation.
read paper →the cathedral and the bazaar
raymond, 1997
how open source actually works. linux development model vs traditional software engineering.
read paper →reflections on trusting trust
thompson, 1984
the turing award lecture that will make you paranoid about compilers. brilliant demonstration of bootstrap attacks.
read paper →out of the tar pit
moseley & marks, 2006
complexity is the enemy. functional programming + relational model as the solution. every programmer should read this.
read paper →programming as theory building
naur, 1985
programming isn't about writing code. it's about building mental models. explains why most software projects fail.
read paper →distributed systems papers
paxos made simple
lamport, 2001
the fundamental consensus algorithm explained clearly. no greek islands this time.
read paper →in search of an understandable consensus algorithm
ongaro & ousterhout, 2014
raft: more practical alternative to paxos. actually understandable by humans.
read paper →the part-time parliament
lamport, 1998
original paxos paper with the greek island metaphor. consensus as archaeology.
read paper →the google file system
ghemawat, gobioff, leung, 2003
foundation for modern distributed storage. how to build reliable systems from unreliable parts.
read paper →bigtable: a distributed storage system
chang et al., 2006
nosql at scale. how google handles petabytes without sql getting in the way.
read paper →dynamo: amazon's highly available key-value store
decandia et al., 2007
eventually consistent systems. when you care more about availability than perfect consistency.
read paper →mapreduce: simplified data processing
dean & ghemawat, 2004
changed how we think about parallel computation. functional programming at datacenter scale.
read paper →time, clocks, and the ordering of events
lamport, 1978
essential for understanding distributed time. logical clocks and happens-before relations.
read paper →the byzantine generals problem
lamport, shostak, pease, 1982
fault tolerance fundamentals. how to reach agreement when some nodes are lying.
read paper →spanner: google's globally-distributed database
corbett et al., 2012
true global consistency with atomic clocks. when you absolutely need correct time.
read paper →large-scale incremental processing
peng & dabek, 2010
percolator: distributed transactions at scale. how google builds incremental systems.
read paper →kafka: a distributed messaging system
kreps, narkhede, rao, 2011
event streaming architecture. the log as the fundamental abstraction.
read paper →essential books
the c programming language
kernighan & ritchie
the book that taught everyone c. still the best way to learn how computers actually work at the system level.
advanced programming in the unix environment
stevens & rago
everything you need to know about unix system programming. processes, files, signals, ipc.
computer systems: a programmer's perspective
bryant & o'hallaron
how computers work from the bottom up. assembly, memory, caching, linking, processes.
operating system concepts
silberschatz, galvin, gagne
comprehensive coverage of os internals. scheduling, memory management, file systems, synchronization.
crafting interpreters
nystrom
build two complete interpreters from scratch. practical guide to language implementation.
structure and interpretation of computer programs
abelson & sussman
how to think about computation. functional programming, interpreters, and the art of abstraction.
designing data-intensive applications
kleppmann
the bible for modern backend systems. databases, queues, caches, and how they all fit together.
distributed systems: principles and paradigms
tanenbaum & van steen
comprehensive intro to distributed systems. covers everything from communication to consistency.
site reliability engineering
beyer, jones, petoff, murphy
how google runs production systems. the sre bible that created a whole industry.
database internals
petrov
deep dive into how databases actually work. storage engines, btrees, lsm trees, transactions.
the art of multiprocessor programming
herlihy & shavit
concurrent programming done right. lock-free algorithms and when to actually use them.
tcp/ip illustrated
stevens
how the internet actually works. packets, routing, tcp internals. stevens at his best.
unix network programming
stevens
sockets, select, poll, epoll. everything you need to build networked systems from scratch.
release it!
nygard
designing and deploying production-ready software. patterns for stability and capacity.
the linux programming interface
kerrisk
comprehensive guide to linux system calls and apis. the modern replacement for stevens.
hands on learning
build your own x
collection of tutorials for building fundamental tools from scratch. git, docker, databases, etc.
view repo →os dev wiki
comprehensive guide to operating system development. everything from bootloaders to file systems.
visit wiki →linux from scratch
build a complete linux system from source code. understand every component.
start building →nand2tetris
build a computer from logic gates up to high level programs. hardware and software stack.
take course →the little book about os development
practical guide to writing a simple operating system. bootloader, kernel, memory management.
read book →writing a compiler in go
build a complete interpreter and compiler. lexing, parsing, evaluation, bytecode compilation.
buy book →why this stuff matters
most programmers today are basically frontend developers who accidentally ended up writing backend code. they import frameworks without understanding what those frameworks do. they write "clean code" without understanding what makes code actually clean.
the industry is full of people who know how to use kubernetes but don't understand what a syscall is. who can configure microservices but can't write a parser. who memorize leetcode patterns but panic when they have to debug actual systems.
this creates the current state of software: bloated, slow, fragile systems built on towers of abstraction that nobody understands. when your mental model is "docker containers and rest apis", you're going to write different code than when your mental model is "processes and file descriptors".
the papers above are the real computer science. not the programming bootcamp stuff, not the enterprise patterns, not the agile methodology nonsense. the foundational work that actually matters.
functional programming gets a lot of space here because it's the only paradigm that's still connected to mathematical reality. lisp was doing things in 1960 that "modern" languages are still trying to figure out. haskell forces you to think about correctness in ways that imperative languages can't.
object oriented programming barely appears because it's mostly a mistake. the useful parts (data encapsulation, polymorphism) existed before oop and work better in other paradigms. the rest is just ceremony that makes your code harder to understand and debug.
read this stuff and you'll understand why simple is better than complex, why data is better than objects, and why understanding the machine matters more than following patterns.