Skip to content
←

Split View: 개발자의 책장 2026 — 다시 읽어야 할 12권의 컴퓨터과학 고전 (큐레이션·이유·읽는 법)

|

개발자의 책장 2026 — 다시 읽어야 할 12권의 컴퓨터과학 고전 (큐레이션·이유·읽는 법)

프롤로그 — AI가 코드를 써 주는 시대에, 왜 책인가

2026년에 책 이야기를 꺼내면 두 가지 반응이 돌아온다. 하나는 "요즘 누가 책 읽나, 모델이 다 해 주는데." 다른 하나는 "맞아요, 근본을 다시 봐야 해요."

둘 다 일면 옳다. 모델은 정말로 많은 코드를 써 준다. 그래서 더 중요한 게 생겼다. 판별. 모델이 생성한 200줄 패치가 옳은가, 옳지 않은가. 빠른가, 느린가. 안전한가, 위험한가. 이 판단은 어디서 오는가. 책에서 가장 잘 자란다.

  • 블로그 글은 사건을 가르친다 — 어제 누가 무엇을 했나.
  • 튜토리얼은 방법을 가르친다 — 이 라이브러리를 어떻게 쓰나.
  • 책은 원칙을 가르친다 — 왜 그렇게 해야 하는가, 그리고 그것이 변하지 않는 이유는 무엇인가.

AI 시대의 개발자에게 책이 더 중요해진 이유는 단순하다. 모델은 방법의 거의 전부를 대체할 수 있다. 그러나 원칙과 판단은 여전히 사람의 머리에 있어야 한다. 그 판단의 재료가 책이다.

이 글은 2026년에 다시 읽거나 처음 읽을 만한 컴퓨터과학·소프트웨어 엔지니어링 고전 12권을 큐레이션한다. 책별로:

  • 무엇을 배우는가 — 핵심 가르침 한 줄
  • 누가 읽어야 하는가 — 신참·중견·시니어 중 누구
  • 2026년에 다시 읽는 이유 — 왜 하필 지금 이 책인가

리스트 자체는 새롭지 않다. 모두 한 번쯤 들어 본 책일 것이다. 그래서 이 글의 가치는 "어떤 책인지"가 아니라 "왜 지금"에 있다. 추가로 책에 준하는 무게를 가진 에세이·논문 몇 편을 보너스로 모았고, 끝에는 무료 PDF·출판사 링크·읽는 순서를 둔다.

책장은 자랑이 아니라 작업 도구다. 읽지 않은 책은 책장에 있어도 머리에는 없다. 12권을 추리는 이유는 그래서다 — 다 읽기 위해서.

한눈에 보는 12권 매트릭스

#책저자초판난이도시간 투자2026년 다시 읽는 이유
1SICPAbelson and Sussman1985상3–6개월50주년. 추상화의 사다리, AI 없는 시대의 사고 훈련
2The Pragmatic Programmer (20주년)Hunt and Thomas1999중2–4주직업 윤리의 갱신, AI 시대에도 유효한 원칙
3Designing Data-Intensive ApplicationsKleppmann2017상1–3개월분산 시스템 표준 교과서, 2판 작업 중
4Code (2판)Petzold1999 / 2022중2주실리콘에서 소프트웨어까지, 추상화 스택의 지도
5Crafting InterpretersNystrom2021중1–2개월무료 온라인. 컴파일러를 두려워하지 않게 된다
6The Mythical Man-MonthBrooks1975 / 1995하1주사람·소프트웨어의 비합리성은 50년째 그대로
7A Philosophy of Software Design (2판)Ousterhout2018 / 2021중1–2주복잡성이라는 적, deep modules의 미덕
8Software Engineering at GoogleWinters et al.2020중1개월큰 코드베이스에서 살아남기, 시간 축의 엔지니어링
9Refactoring (2판)Fowler2018중3–4주AI가 리팩터하는 시대의 인간 감수 기준
10OSTEP (Three Easy Pieces)Arpaci-Dusseau2018중1–2개월무료. 운영체제 직관의 황금 표준
11CSAPP (3판)Bryant and O'Hallaron2002 / 2015상2–4개월프로그래머의 관점에서 본 컴퓨터 시스템
12The C Programming Language (K&R)Kernighan and Ritchie1978 / 1988하1–2주명료함의 본보기. 짧은 책의 위엄
Bonus ABuild a Large Language Model (from Scratch)Raschka2024중1개월LLM 내부를 손으로 만들어 보는 시간
Bonus BDesigning Machine Learning SystemsHuyen2022중3–4주ML 시스템의 DDIA, 2026년 ML 엔지니어의 기본서

"시간 투자"는 진지하게 읽고 연습 문제를 일부 하는 기준이다. 통독은 1/3 정도면 된다.

1장 · SICP — Structure and Interpretation of Computer Programs

  • 저자 — Harold Abelson, Gerald Jay Sussman, with Julie Sussman
  • 무엇을 배우는가 — 추상화의 사다리. 절차적 추상화에서 데이터 추상화로, 그리고 메타순환 평가기·레지스터 머신까지. 언어가 아니라 사고의 골격을 만든다.
  • 누가 읽어야 하는가 — 신참부터 시니어까지. 단, 시간이 있을 때. SICP는 빨리 끝내는 책이 아니라 천천히 사는 책이다.
  • 2026년에 다시 읽는 이유 — 50주년. 1985년 초판, 1996년 2판. 2026년에 추상화 능력은 더 중요해졌다. AI가 코드 생성을 대신해도, "이 코드가 어떤 추상의 어느 층에 있는가"를 보는 눈은 사람이 가지고 있어야 한다. SICP는 그 눈을 만드는 데 가장 효율적인 책이다.
  • 읽는 법 — 1·2·3장은 반드시. 4장(메타순환 평가기)을 끝내면 인터프리터에 대한 두려움이 사라진다. JavaScript 판(SICP JS)도 있어서 Scheme이 부담이면 그쪽으로.
  • 함정 — Scheme 문법이 아니라 개념이 핵심이다. 문법에 막혀 포기하지 말 것.

2장 · The Pragmatic Programmer (20주년 기념판)

  • 저자 — David Thomas, Andrew Hunt
  • 무엇을 배우는가 — 개발자의 직업 윤리. DRY, 직교성, 깨진 창문 이론, 신뢰할 수 있는 추정, 일찍 자주 리팩터. 한 챕터에 한 가지 원칙, 한 가지 비유.
  • 누가 읽어야 하는가 — 전부. 특히 1–3년차에 읽으면 다음 5년이 다르다.
  • 2026년에 다시 읽는 이유 — 1999년 초판 이후 20주년 개정판(2019)이 나왔다. AI 도구를 다루는 챕터는 없지만, 놀랍게도 그래도 거의 다 유효하다. "코드를 생성하는 도구의 출력에 책임을 진다"는 태도는 이 책의 정신과 정확히 같다.
  • 읽는 법 — 처음부터 끝까지 한 번 통독, 1년 후 다시 통독. 챕터가 짧아서 침대 머리맡 책으로 좋다.
  • 함정 — "원칙"이 멋져 보여도 코드를 안 쓰면 의미가 없다. 매 챕터 끝의 연습 문제를 자기 코드베이스에 한 번이라도 적용해 볼 것.

3장 · Designing Data-Intensive Applications (DDIA)

  • 저자 — Martin Kleppmann
  • 무엇을 배우는가 — 분산 시스템의 모든 것. 복제·파티셔닝·트랜잭션·일관성·합의·스트림 처리. 단지 카프카·카산드라가 아니라 그 밑의 원리.
  • 누가 읽어야 하는가 — 백엔드·인프라·데이터 엔지니어 전원. 2년차부터.
  • 2026년에 다시 읽는 이유 — 2017년에 나왔지만 여전히 분산 시스템의 표준 교과서. Kleppmann이 2판을 작업 중이라는 소식이 있어, 2026년 시점에는 1판을 끝내 두는 게 자산이다. 또한 데이터베이스 마이그레이션, 이벤트 스트리밍, 합의 알고리즘(Raft)이 일상 업무가 된 시대에 이 책은 공통 어휘가 된다.
  • 읽는 법 — 1·2·3장(데이터 모델·인코딩·저장)은 첫 통독에, 5·7·9장(복제·트랜잭션·일관성)은 이해될 때까지 반복. 12장(미래)은 가볍게.
  • 함정 — 두껍다. 1년에 한 챕터씩이라도 진도를 빼는 게 통독 시도하다 중단보다 낫다.

4장 · Code: The Hidden Language of Computer Hardware and Software (2판)

  • 저자 — Charles Petzold
  • 무엇을 배우는가 — 모스 부호에서 시작해서 손전등 → 릴레이 → 트랜지스터 → 논리 게이트 → CPU → 어셈블리 → 고급 언어로 올라가는 추상화 스택의 전 여정.
  • 누가 읽어야 하는가 — 신참·문과 전공 개발자에게 특히. 시니어도 즐거운 복습이 된다.
  • 2026년에 다시 읽는 이유 — 2022년에 2판이 나왔다. 2판은 GUI·인터넷까지 다룬다. 우리는 LLM·GPU·Kubernetes 위에서 살지만, 그 밑에 있는 게 무엇인지를 잊으면 안 된다. 추상화 누수(leaky abstraction)는 결국 그 밑을 보러 내려가야 잡힌다.
  • 읽는 법 — 처음부터 끝까지. 그림이 많아 읽는 속도가 빠르다.
  • 함정 — 너무 친절해서 가볍게 느껴지지만, 그 친절함이 핵심이다. 같은 내용을 다른 책에서 만나면 보통 훨씬 어렵다.

5장 · Crafting Interpreters

  • 저자 — Robert Nystrom
  • 무엇을 배우는가 — Lox라는 작은 언어의 인터프리터를 두 번 만든다 — 한 번은 트리워킹(Java), 한 번은 바이트코드 VM(C). 어휘 분석·파싱·환경·클로저·클래스·GC·해시테이블까지 직접 구현.
  • 누가 읽어야 하는가 — 컴파일러가 무서운 모든 사람. 신참부터 시니어까지.
  • 2026년에 다시 읽는 이유 — 2021년 책이지만 무료로 온라인에서 전부 공개되어 있고, 매년 업데이트된다. AI가 코드를 쓰는 시대에도, "이 언어가 내부에서 어떻게 동작하는가"를 아는 것은 디버깅 능력의 근본이다. 게다가 LLM·DSL·자체 구성 언어를 만드는 일이 흔해진 2026년에 이 책은 실용적이기까지 하다.
  • 읽는 법 — craftinginterpreters.com에서 처음부터 따라간다. 코드는 직접 타이핑. 1부(Java) 끝나면 큰 산을 넘은 것이고, 2부(C VM) 끝나면 작은 영웅이 된다.
  • 함정 — 책 외부에서 멋진 컴파일러 책을 사기 전에, 이 책을 끝까지 따라가 볼 것. Dragon Book보다 훨씬 빠른 길이다.

6장 · The Mythical Man-Month

  • 저자 — Frederick P. Brooks Jr.
  • 무엇을 배우는가 — 인력을 더 투입한다고 일정이 짧아지지 않는다(Brooks의 법칙). 은총알은 없다. 두 번째 시스템 효과. 외과수술팀 모델. 1975년에 IBM OS/360을 만든 사람의 회고.
  • 누가 읽어야 하는가 — 팀을 이끌거나 곧 이끌게 될 사람 전부. 1주일에 끝낼 수 있다.
  • 2026년에 다시 읽는 이유 — 1975년에 쓰인 이 책이 2026년에도 정확하다는 사실 자체가 메시지다. 사람과 소프트웨어의 비합리성은 변하지 않는다. AI 코딩 에이전트가 들어와도, "더 많은 에이전트를 붙이면 더 빨라진다"는 단순 가정은 여전히 무너진다. 1995년 20주년판에는 "은총알은 없다" 에세이가 부록으로 들어가 있다 — 반드시 읽을 것.
  • 읽는 법 — 짧다. 1주일이면 충분.
  • 함정 — 일부 예시(OS/360, IBM의 폼)는 낡았지만 원리는 안 낡았다. 표면만 보고 무시하지 말 것.

7장 · A Philosophy of Software Design (2판)

  • 저자 — John Ousterhout
  • 무엇을 배우는가 — 복잡성이 곧 소프트웨어 설계의 적이다. Deep modules(좁은 인터페이스 + 풍부한 기능), 정보 은닉, 일반 목적의 모듈, "전략적 프로그래밍". 짧지만 밀도가 높다.
  • 누가 읽어야 하는가 — 3년차 이상. 본인이 짠 코드를 1년 후 다시 보고 한숨이 나온 경험이 있는 모두.
  • 2026년에 다시 읽는 이유 — Ousterhout는 Tcl·Log-Structured File System의 저자이고 Stanford에서 소프트웨어 설계를 가르친 사람이다. 2판(2021)에서는 학생들과의 코드 리뷰 사례가 보강됐다. 2026년 시점에 AI가 쓰는 코드는 얕은 모듈(thin wrapper)을 너무 쉽게 양산한다. 이 책의 "deep module" 기준은 AI 코드의 좋은 감수자(reviewer) 척도가 된다.
  • 읽는 법 — 짧다(약 200쪽). 한 번 통독, 본인 코드 리뷰할 때 옆에 두기.
  • 함정 — 일부 의견(주석에 대한 강한 옹호 등)은 책 밖에서 논쟁이 있다. 그 논쟁을 추적하면 더 재밌다.

8장 · Software Engineering at Google

  • 저자 — Titus Winters, Tom Manshreck, Hyrum Wright (편)
  • 무엇을 배우는가 — 코드가 아니라 소프트웨어 엔지니어링이 무엇인지. "프로그래밍은 시간을 가로질러 통합된 것이다." 코드 리뷰·테스팅·정적 분석·의존성·라지 스케일 변경(LSC)·빌드 시스템 — 큰 코드베이스에서 살아남는 방법.
  • 누가 읽어야 하는가 — 중대형 회사에서 일하는 모든 엔지니어. 시니어 후보생에게는 거의 필수.
  • 2026년에 다시 읽는 이유 — 2020년 책. AI 코딩 에이전트가 라지 스케일 변경(LSC)을 만들 수 있게 된 2026년에 이 책은 더 실용적이다. "코드를 어떻게 안전하게 바꾸는가"는 모델이 답해 주지 않는다 — 사람이 정책으로 정해야 한다.
  • 읽는 법 — 5장(Code Review), 11장(Testing Overview), 17장(Static Analysis), 22장(Large-Scale Changes)을 먼저. 전체를 다 안 봐도 된다.
  • 함정 — 책이 너무 두꺼워서 통독을 시도하면 좌절한다. 챕터 단위로 필요할 때 본다.

9장 · Refactoring (2판)

  • 저자 — Martin Fowler (with Kent Beck)
  • 무엇을 배우는가 — 리팩터링을 일상으로 만드는 방법. 코드 스멜의 카탈로그, 안전한 변환의 카탈로그, 테스트가 어떻게 리팩터를 가능하게 하는가. 2판은 JavaScript 예시로 갱신.
  • 누가 읽어야 하는가 — 모든 개발자. 특히 "이 코드 한 줄도 못 건드리겠다"는 코드베이스에서 일하는 사람.
  • 2026년에 다시 읽는 이유 — AI 도구가 리팩터링 자체는 잘한다. 그러나 무엇을 리팩터해야 하는지의 판단은 사람이 한다. Fowler의 코드 스멜 목록은 그 판단의 어휘다. 또한 모델이 만든 250줄 패치를 보고 "여기는 Extract Function이 필요하다"고 한 줄로 말할 수 있는 사람은 가치가 높다.
  • 읽는 법 — 1·2장은 통독, 카탈로그(3장 이후)는 사전처럼 참조.
  • 함정 — 카탈로그 외우는 게 목적이 아니다. 이름을 안다는 게 핵심이다 — Extract Function이라는 이름을 알면 다음에 그 패턴을 보았을 때 알아본다.

10장 · Operating Systems: Three Easy Pieces (OSTEP)

  • 저자 — Remzi H. and Andrea C. Arpaci-Dusseau
  • 무엇을 배우는가 — 운영체제의 세 가지 큰 조각 — 가상화(CPU·메모리), 동시성, 영속성(파일시스템). 짧은 챕터, 풍부한 예시, 친절한 설명.
  • 누가 읽어야 하는가 — 시스템 프로그래밍·인프라·DB·OS 일을 하는 모두. 비CS 전공 후 입사한 개발자에게 특히.
  • 2026년에 다시 읽는 이유 — 완전히 무료. PDF·HTML로 공개. 2018년판이 안정 버전이고, 매년 작은 수정이 들어간다. 컨테이너·VM·eBPF·서버리스가 일상이 된 2026년에 OS 추상화는 더 중요해졌다. "이게 왜 느리지?"의 답이 OS 어딘가에 있는 경우는 늘었다.
  • 읽는 법 — 가상화부터. 챕터별로 짧아서 통근 시간에도 가능. 끝에는 동시성·파일시스템.
  • 함정 — 무료라서 "언젠가 읽어야지"가 되기 쉽다. 첫 일주일에 첫 3장을 강제로 끝내 보면 가속이 붙는다.

11장 · Computer Systems: A Programmer's Perspective (CSAPP, 3판)

  • 저자 — Randal E. Bryant, David R. O'Hallaron
  • 무엇을 배우는가 — 프로그래머의 관점에서 본 하드웨어·OS·네트워크. 비트·바이트·메모리 계층·캐시·가상 메모리·시스템 콜·네트워킹까지. 카네기멜런 입문 시스템 수업의 교재.
  • 누가 읽어야 하는가 — 시스템·성능·인프라에 관심 있는 모든 사람. 신참부터.
  • 2026년에 다시 읽는 이유 — 2015년 3판이 여전히 표준. 2026년에 AI 학습/추론은 결국 하드웨어 효율의 문제로 수렴한다. 캐시·페이지·메모리 대역폭을 모르고 GPU 클러스터를 다룰 수 없다. CSAPP는 그 기초의 단단함을 만든다. CMU의 무료 강의(15-213/15-513)와 함께 보면 더 좋다.
  • 읽는 법 — 2장(데이터 표현), 3장(어셈블리), 6장(메모리 계층), 9장(가상 메모리)은 필수. 11·12장(네트워킹·동시성)은 선택.
  • 함정 — 무겁다. 한 번에 다 보려 하면 부서진다. 필요 챕터부터.

12장 · The C Programming Language (K&R)

  • 저자 — Brian W. Kernighan, Dennis M. Ritchie
  • 무엇을 배우는가 — C 그 자체. 그리고 명료함이라는 미덕. 250페이지 안에 한 언어와 그 표준 라이브러리, 그리고 가르치는 사람의 절제된 문체.
  • 누가 읽어야 하는가 — 모든 개발자. 특히 C를 안 쓸 사람일수록 — 짧은 책의 위엄이 무엇인지 보러.
  • 2026년에 다시 읽는 이유 — 1978년 초판, 1988년 2판. 거의 50년 전 책이다. 그런데도 여전히 좋은 글쓰기의 본보기다. 코드는 어떻게 짧게 쓸 수 있는가, 문서는 어떻게 군더더기 없이 쓸 수 있는가 — 모델이 장황한 글을 끝없이 생성하는 시대에 이 책의 절제는 거의 도덕적 메시지에 가깝다.
  • 읽는 법 — 1·5장은 반드시(포인터·배열). 나머지는 가볍게.
  • 함정 — C로 일을 시작하려고 보는 책이 아니다. 명료함을 배우러 보는 책이다.

보너스 A · Build a Large Language Model (from Scratch)

  • 저자 — Sebastian Raschka
  • 무엇을 배우는가 — 토큰화·어텐션·트랜스포머·사전학습·미세조정·지시 조정까지 LLM을 손으로 만든다. PyTorch만 사용, 외부 라이브러리 최소.
  • 누가 읽어야 하는가 — LLM을 쓰지만 내부가 궁금한 ML/AI 엔지니어. 응용 개발자에게도 권한다.
  • 2026년에 다시 읽는 이유 — 2024년 책. 2026년 시점에 LLM은 일상 도구가 됐고, 더 이상 "오픈AI의 마법"이 아니다. 내부를 한 번 손으로 만든 사람과 안 만든 사람의 디버깅·튜닝 직관은 다르다. GitHub의 부속 코드와 함께 따라가면 한 달이면 끝난다.
  • 읽는 법 — GitHub 리포의 노트북을 챕터 순서대로. 직접 GPT를 작은 규모로 학습시켜 볼 것.
  • 함정 — "LLM 사용법" 책이 아니다. 내부 메커니즘 책이다.

보너스 B · Designing Machine Learning Systems

  • 저자 — Chip Huyen
  • 무엇을 배우는가 — ML 시스템 설계의 DDIA. 데이터 파이프라인, 피처, 학습·서빙·모니터링, 데이터/모델 드리프트, ML 인프라. 모델 아니라 시스템.
  • 누가 읽어야 하는가 — 프로덕션에서 ML을 운영하는 모든 엔지니어.
  • 2026년에 다시 읽는 이유 — 2022년 책이지만 LLM 시대에도 핵심 원리는 그대로다. RAG·미세조정·온라인 학습이 일상이 된 2026년에 "이 모델이 실서비스에서 어떻게 살아가는가"의 질문은 더 중요해졌다.
  • 읽는 법 — 1·2·8·9장을 우선. 코드보다 시스템 그림을 그려가며.
  • 함정 — Chip Huyen의 후속 책(AI Engineering, 2024)도 좋지만, ML 시스템 기초로는 이 책이 먼저다.

보너스 섹션 · 책에 준하는 무게의 에세이·논문

책 12권으로 부족할 때, 한 편의 글이 한 권을 대신하는 경우가 있다. 분량은 작지만 밀도가 책급인 에세이/논문 모음.

Joel Spolsky — Joel on Software

  • The Joel Test (2000) — 12개 질문으로 팀의 엔지니어링 성숙도를 잰다. 2026년에도 절반 이상이 여전히 유효.
  • The Law of Leaky Abstractions (2002) — 모든 추상화는 새고, 그것을 모르면 더 다친다.
  • Things You Should Never Do, Part I (2000) — 처음부터 다시 쓰지 말라. 모든 리라이트 추진자가 읽어야 한다.

Steve Yegge

  • Practical Magic (2007) — 추상화에 대해 가장 인간적인 글 중 하나.
  • Have You Ever Legalized Marijuana? / Get That Job at Google — 인터뷰·커리어에 대한 솔직한 글들. 시간이 지나도 살아남는다.
  • Notes from the Mystery Machine Bus — 보수파 vs. 자유파 프로그래머의 분류. 한 번 읽으면 잊지 못한다.

Dijkstra의 EWDs

  • EWD 1036 — On the Cruelty of Really Teaching Computer Science (1988) — CS를 가르치는 게 왜 자비롭지 못한 것에 가까운가. 짧고 잔인하고 옳다.
  • EWD 215 — A Case against the GOTO Statement (1968) — 한 통의 편지가 산업의 코드 스타일을 바꿨다.

Paul Graham

  • Beating the Averages (2003) — Lisp 이야기이지만 본질은 도구의 선택과 평균에 대한 거리.
  • Maker's Schedule, Manager's Schedule (2009) — 만드는 사람의 시간과 관리하는 사람의 시간. 캘린더의 폭력에 대한 가장 좋은 글.

Hamming — You and Your Research (1986)

  • "왜 어떤 사람은 큰 연구를 하고 어떤 사람은 못하는가." Hamming의 벨 연구소 강연. 모든 시니어가 한 번은 본다.

Bret Victor

  • Up and Down the Ladder of Abstraction (2011) — 인터랙티브 에세이. 추상화의 단계를 미디어로 보여 준다.
  • Inventing on Principle (2012) — 강연이지만 본문 못지않게 인용된다. 도구 만드는 사람의 원칙.

Lamport — Time, Clocks, and the Ordering of Events (1978)

  • 분산 시스템 시간 개념의 출발. 짧고 어렵고 아름답다. 한 번은 직접 따라가 볼 만하다.

책 1권이 너무 멀게 느껴질 때, 위 에세이 중 한 편을 읽는다. 한 편이면 충분히 그 일주일이 바뀐다.

읽는 순서 추천

12권을 다 읽는 것은 목적이 아니지만, 시작점은 있을수록 좋다.

0–2년차 개발자

  1. The Pragmatic Programmer — 직업 윤리의 기초
  2. Code (Petzold) — 추상화 스택의 지도
  3. The Mythical Man-Month — 팀과 일정의 진실
  4. K&R — 명료함의 본보기

여기까지 1년이면 충분하고, 직업관과 어휘가 자란다.

2–5년차 개발자

  1. A Philosophy of Software Design — 모듈 설계 감각
  2. Refactoring — 변경 가능성을 유지하는 기술
  3. Crafting Interpreters — 컴파일러 두려움 제거
  4. OSTEP — OS 직관

여기까지 1–2년. 기술 깊이가 늘기 시작.

5–10년차 개발자

  1. DDIA — 분산 시스템 공통 어휘
  2. CSAPP — 하드웨어까지 내려가는 시야
  3. Software Engineering at Google — 큰 코드베이스의 정치학
  4. SICP — 한 번은 끝까지 가 보는 산행

ML 트랙 보강

  • Build a Large Language Model (from Scratch) — LLM 내부 손으로
  • Designing Machine Learning Systems — ML 시스템 원리

"순서"는 강한 권유가 아니라 약한 안내다. 회사에서 분산 시스템 일을 시작했다면 2년차여도 DDIA부터. 도구가 일을 끌어 준다.

책을 잘 읽는 작은 기술

이 12권은 모두 두껍거나 어려운 경향이 있다. 잘 읽는 작은 기술 몇 가지.

1. 통독은 1/3만, 정독은 1/10만

두꺼운 기술서는 1/3 정도면 충분히 읽었다고 친다. 정독은 1/10. 책 전체를 정독하려는 시도가 가장 흔한 실패 원인이다.

2. 한 챕터에 한 노트

각 챕터에서 단 한 가지만 메모로 남긴다. "이 챕터는 무엇을 말하나"를 한 문장으로. 책 한 권의 노트가 30문장 안에 들어오면 잘 읽은 것이다.

3. 코드는 직접 친다

특히 SICP·Crafting Interpreters·OSTEP·CSAPP·LLM from Scratch — 코드를 그대로 옮겨 친다. 읽기만 한 챕터와 친 챕터의 흡수율은 5배 차이가 난다.

4. 그룹 스터디는 강력하다

회사에서 책 모임을 1년 단위로 돌리면, 평소엔 손이 안 갈 책이 끝까지 간다. DDIA·CSAPP·SICP는 특히 그룹에서 강력하다.

5. 책의 정답은 출제자의 의도가 아니다

기술서의 본문보다 연습 문제가 본질을 더 잘 가르치는 책이 있다. SICP·CSAPP·OSTEP·LLM from Scratch가 그렇다. 문제를 풀지 않으면 그 책의 절반만 읽은 것이다.

흔한 함정

  • 책장만 자라고 머리는 안 자란다 — "사 두면 언젠가" 라는 생각은 책장만 채운다. 사는 책을 줄이고, 끝내는 책을 늘려라.
  • 유행에 흔들린다 — 매주 새 책 추천 트윗이 올라온다. 12권 안에 안 들어가면 일단 미뤄도 된다. 고전이 고전인 이유는 5년 뒤에도 같은 위치에 있어서다.
  • 번역과 원서 사이 — 번역이 좋은 책은 한국어로 읽는 게 빠르다. K&R·Mythical Man-Month·Pragmatic Programmer는 번역이 좋다. SICP·DDIA·CSAPP는 원서 권장(또는 영문 PDF 무료판 활용).
  • 무료라서 안 읽는다 — OSTEP·Crafting Interpreters는 무료라서 자꾸 미뤄진다. 첫 주에 첫 3장을 강제로 끝내라.
  • 읽고 안 적용한다 — 책의 한 원칙을 본인 코드베이스에 한 번이라도 적용하지 않으면, 그 책은 머리에 없다.

에필로그 — 정수만 남기는 시대에

AI가 매일 좋아지는 시대에 책을 읽으라는 권유는 시대를 거스르는 것처럼 보일 수 있다. 그러나 정반대다. 모델이 더 잘할수록, 사람의 머리에 남아 있어야 할 것은 더 정수만 남는다. 그 정수는 책에서 가장 잘 자란다.

이 글이 권하는 것은 12권을 다 읽으라는 명령이 아니다. 본인의 자리에서 한 권부터 시작하라는 권유다. 1–2년차라면 The Pragmatic Programmer. 3–5년차라면 A Philosophy of Software Design. 5–10년차라면 DDIA. 그 한 권이 끝나면, 다음 한 권을 정하는 것은 자연스럽다.

읽는 데 시간이 든다. 하지만 모델이 코드를 써 주는 시대에 그 시간은 이제 더 남는다. 옛날에는 다섯 시간 동안 코드를 쳤다면, 지금은 다섯 시간 중 한 시간이 코드, 두 시간이 검토, 두 시간이 생각이다. 그 "생각"의 재료가 어디서 오는가. 책에서 가장 잘 자란다.

12권 체크리스트

다 끝낸 책에 체크.

  • SICP — 한 번은 끝까지
  • The Pragmatic Programmer — 1년에 한 번 통독
  • DDIA — 챕터별로라도
  • Code (Petzold) — 한 번
  • Crafting Interpreters — 무료다, 끝까지
  • The Mythical Man-Month — 1주일에
  • A Philosophy of Software Design — 200쪽이다
  • Software Engineering at Google — 필요 챕터부터
  • Refactoring — 카탈로그를 손이 닿게
  • OSTEP — 무료다, 첫 3장
  • CSAPP — 메모리 계층 챕터부터
  • K&R — 명료함을 배우러

다음 글 예고

  • "오픈소스 기여 가이드 — 첫 PR부터 메인테이너까지" — 책에서 배운 것을 실제 코드베이스에 적용하는 가장 좋은 방법.
  • "개발자의 글쓰기 — 블로그·뉴스레터·기술 문서로 청중을 만들기" — 읽기의 반대편, 쓰기에 대해.
  • "AI 시대의 개발자 다음 커리어 — 코더가 아니라 빌더로" — 책으로 단단해진 판단을 어디에 쓸 것인가.

이 시리즈 안에서 책장은 한 챕터에 해당한다.

참고 / References

책 — 공식 페이지·출판사

에세이·강연

무료 강의·동영상(부록)

"고전을 읽는 일의 가장 큰 보상은, 그 책 자체가 아니라 그 책을 통과한 후의 내 판단이다."

— 개발자의 책장 2026, 끝.

The Developer's Bookshelf 2026 — Twelve CS Classics Worth (Re)Reading, With the 2026 Reason for Each

Prologue — Why books, in an age when models write code?

Bring up books with developers in 2026 and you get two reactions. One: "Who reads books these days? The model does it for me." Two: "Yes, we need to return to fundamentals."

Both are partly right. Models genuinely write a lot of code, and that has made one thing more important than ever: judgment. Is the 200-line patch the model just wrote correct? Fast? Safe? Maintainable? Where does the answer come from? It grows best in books.

  • Blog posts teach you events — what someone did yesterday.
  • Tutorials teach you methods — how to use this library.
  • Books teach you principles — why we do it this way, and why that reason doesn't change.

Models can absorb almost the entirety of "methods." Principles and judgment still have to live in your head. Books are where those grow.

This essay curates twelve CS / software-engineering classics worth reading (or rereading) in 2026. For each book:

  • What it teaches — the core lesson in one sentence.
  • Who should read it — junior, mid, senior.
  • The 2026 reason — why now, not 1985 or 1999.

The list itself isn't novel. You'll have heard of every book. The value of this essay isn't which books — it's why now. A bonus section covers essays and papers that earned book-equivalent status. At the end you'll find free PDFs, publisher links, and a suggested reading order.

A bookshelf is a working tool, not a trophy. Twelve is small for a reason — small enough to actually finish.

The twelve at a glance

#BookAuthor(s)First Ed.DifficultyTimeThe 2026 reason
1SICPAbelson and Sussman1985High3–6 mo50th anniversary; abstraction-ladder training without AI shortcuts
2The Pragmatic Programmer (20th)Hunt and Thomas1999Mid2–4 wkProfessional ethics; still valid in the AI era
3Designing Data-Intensive ApplicationsKleppmann2017High1–3 moStandard distributed-systems text; 2nd ed. in progress
4Code (2nd ed.)Petzold1999 / 2022Mid2 wkSilicon to software; the map of the abstraction stack
5Crafting InterpretersNystrom2021Mid1–2 moFree online; cures the fear of compilers
6The Mythical Man-MonthBrooks1975 / 1995Low1 wkHuman and software irrationality hasn't moved in 50 years
7A Philosophy of Software Design (2nd)Ousterhout2018 / 2021Mid1–2 wkComplexity is the enemy; deep modules as virtue
8Software Engineering at GoogleWinters et al.2020Mid1 moSurviving a large codebase; engineering across time
9Refactoring (2nd ed.)Fowler2018Mid3–4 wkThe human standard for AI-driven refactors
10OSTEP (Three Easy Pieces)Arpaci-Dusseau2018Mid1–2 moFree; the gold-standard OS intuition book
11CSAPP (3rd ed.)Bryant and O'Hallaron2002 / 2015High2–4 moComputer systems from a programmer's perspective
12The C Programming Language (K&R)Kernighan and Ritchie1978 / 1988Low1–2 wkA short book as a model of clarity
Bonus ABuild a Large Language Model (from Scratch)Raschka2024Mid1 moBuild an LLM with your own hands
Bonus BDesigning Machine Learning SystemsHuyen2022Mid3–4 wkThe DDIA of ML systems

"Time" assumes a serious read with some exercises. Skim-reading is roughly one third of that.

1. SICP — Structure and Interpretation of Computer Programs

  • Authors — Harold Abelson, Gerald Jay Sussman, with Julie Sussman.
  • What it teaches — The ladder of abstraction. From procedural abstraction to data abstraction to metacircular evaluators and register machines. The book trains a way of thinking, not a language.
  • Who should read it — Anyone from junior to senior, when time allows. SICP isn't meant to be sprinted through; it's lived with.
  • The 2026 reason — Fiftieth anniversary. First edition 1985, second edition 1996. Abstraction skill has only become more important: even with AI generating code, you still need to see which abstraction layer a piece of code sits at. SICP is the single most efficient book for building that eye.
  • How to read it — Chapters 1–3 are essential. Finishing chapter 4 (the metacircular evaluator) removes most of the mystery of interpreters. The SICP JS adaptation exists if Scheme feels like a wall.
  • Trap — The point is concepts, not Scheme syntax. Don't let the syntax stop you.

2. The Pragmatic Programmer (20th Anniversary Edition)

  • Authors — David Thomas, Andrew Hunt.
  • What it teaches — Professional ethics for developers. DRY, orthogonality, broken windows, trustworthy estimates, refactor early and often. One principle per short chapter, one memorable analogy each.
  • Who should read it — Everyone. Read in years 1–3, the next five years go differently.
  • The 2026 reason — Original 1999, 20th-anniversary revision 2019. There's no chapter about AI tools, yet almost every chapter still applies cleanly. "You're responsible for the output of the tools that generate your code" is precisely the spirit of this book.
  • How to read it — Read through once cover to cover; reread a year later. Short chapters make it ideal bedside reading.
  • Trap — Principles are useless if they don't touch your code. After each chapter, try applying that principle once in your actual codebase.

3. Designing Data-Intensive Applications (DDIA)

  • Author — Martin Kleppmann.
  • What it teaches — Distributed systems, end to end. Replication, partitioning, transactions, consistency, consensus, stream processing. Not Kafka or Cassandra specifically — the principles underneath them.
  • Who should read it — Every backend, infra, and data engineer, from year two onward.
  • The 2026 reason — Published in 2017, still the standard text. Kleppmann is working on a second edition; finishing the first is an asset for when the second lands. In a world where database migrations, event streaming, and consensus (Raft) are everyday work, this book gives you the common vocabulary.
  • How to read it — Chapters 1, 2, 3 (data models, encoding, storage) first. Reread 5, 7, 9 (replication, transactions, consistency) until they click. Chapter 12 (future) is a light read.
  • Trap — It's a thick book. A chapter a year beats abandoned cover-to-cover attempts.

4. Code: The Hidden Language of Computer Hardware and Software (2nd ed.)

  • Author — Charles Petzold.
  • What it teaches — Morse code to flashlights to relays to transistors to logic gates to CPUs to assembly to high-level languages — the whole journey up the abstraction stack.
  • Who should read it — Especially good for self-taught developers and CS career-switchers. Senior engineers also enjoy it as a pleasurable refresher.
  • The 2026 reason — Second edition appeared in 2022, extending into GUIs and the internet. We live on top of LLMs, GPUs, and Kubernetes, but you have to remember what's underneath. Leaky abstractions can only be caught by descending into the layer below.
  • How to read it — Front to back. The illustrations carry the pace.
  • Trap — Its friendliness can make it feel slight, but the friendliness is the point. The same content in a different book is usually much harder.

5. Crafting Interpreters

  • Author — Robert Nystrom.
  • What it teaches — Build an interpreter for a small language (Lox) twice — once as a tree-walker in Java, once as a bytecode VM in C. Lexing, parsing, environments, closures, classes, garbage collection, hash tables — all hand-built.
  • Who should read it — Anyone afraid of compilers. Juniors through seniors.
  • The 2026 reason — Published 2021, but the full text is free online and the author updates it regularly. Even with AI writing code, knowing how a language actually runs is the foundation of debugging skill. Plus, in 2026 building LLM-driven DSLs and small custom languages has become common — so the book is practically useful, not just educational.
  • How to read it — Follow along on craftinginterpreters.com. Type the code yourself. Finishing Part I (Java tree-walker) feels like crossing a mountain; finishing Part II (C VM) feels like becoming a small hero.
  • Trap — Don't buy a fancier compilers book before finishing this one. It's a much faster path than the Dragon Book.

6. The Mythical Man-Month

  • Author — Frederick P. Brooks Jr.
  • What it teaches — Adding people to a late project makes it later (Brooks's Law). There is no silver bullet. The second-system effect. The surgical team. Memoir from the man who shipped IBM OS/360 in 1975.
  • Who should read it — Anyone who leads or will soon lead a team. One week is enough.
  • The 2026 reason — That a 1975 book remains accurate in 2026 is itself the message. The irrationality of humans and software hasn't moved. Even with AI coding agents, "throw more agents at it and we'll go faster" still breaks for the same reasons. The 1995 20th-anniversary edition includes the "No Silver Bullet" essay as an appendix — required.
  • How to read it — Short. A week is plenty.
  • Trap — Some specifics (OS/360, IBM forms) are dated, but the principles haven't dated. Don't dismiss it by its surface.

7. A Philosophy of Software Design (2nd ed.)

  • Author — John Ousterhout.
  • What it teaches — Complexity is the enemy of software design. Deep modules (narrow interface, rich behavior), information hiding, general-purpose modules, "strategic programming." Short, dense.
  • Who should read it — Year three and up. Anyone who has groaned reading code they wrote a year ago.
  • The 2026 reason — Ousterhout authored Tcl and the Log-Structured File System and teaches software design at Stanford. The 2nd edition (2021) adds more code-review examples from his class. In 2026, AI-generated code tends to spawn shallow modules (thin wrappers); Ousterhout's "deep module" criterion is exactly the right reviewer's yardstick.
  • How to read it — Short — about 200 pages. Read through once, then keep it next to your editor for code reviews.
  • Trap — Some opinions (notably strong defense of comments) are contested. Following that debate online makes the book more interesting.

8. Software Engineering at Google

  • Editors — Titus Winters, Tom Manshreck, Hyrum Wright.
  • What it teaches — Not "code" but software engineering: "programming is what we do; engineering is programming integrated over time." Code review, testing, static analysis, dependencies, large-scale changes (LSCs), build systems. Surviving a multi-million-line codebase.
  • Who should read it — Anyone working in a mid-to-large codebase. Near-essential for senior candidates.
  • The 2026 reason — Published 2020. In 2026 AI coding agents can produce LSC-scale changes, which makes this book more practical, not less. "How do we safely change code at scale?" is not a question the model answers — humans must set the policy.
  • How to read it — Chapter 5 (Code Review), 11 (Testing Overview), 17 (Static Analysis), 22 (Large-Scale Changes) first. You don't need the whole book.
  • Trap — Trying to read cover to cover usually leads to giving up. Pick chapters as needed.

9. Refactoring (2nd ed.)

  • Authors — Martin Fowler, with Kent Beck.
  • What it teaches — How to make refactoring an everyday activity. The code-smell catalog, the safe-transformation catalog, how tests enable refactors. The second edition uses JavaScript examples.
  • Who should read it — Every developer, especially those stuck in codebases where "no one dares change anything."
  • The 2026 reason — AI tools do the refactor mechanically. What to refactor remains a human judgment, and Fowler's catalog of code smells is the vocabulary for that judgment. Engineers who can look at a 250-line AI patch and say "this needs an Extract Function here" in one sentence are valuable.
  • How to read it — Read chapters 1 and 2; treat the catalog (chapter 3 onward) as a reference manual.
  • Trap — The point isn't to memorize the catalog. The point is knowing the names — once "Extract Function" is in your head, you recognize the pattern the next time you see it.

10. Operating Systems: Three Easy Pieces (OSTEP)

  • Authors — Remzi H. and Andrea C. Arpaci-Dusseau.
  • What it teaches — The three big pieces of OS: virtualization (CPU and memory), concurrency, persistence (file systems). Short chapters, plenty of examples, a friendly voice.
  • Who should read it — Systems programmers, infra and DB engineers, OS-adjacent folks. Especially valuable for developers without a CS degree.
  • The 2026 reason — Completely free. PDF and HTML. The 2018 edition is the stable baseline with occasional minor revisions. In 2026, containers, VMs, eBPF, and serverless are daily work, so OS abstractions matter more, not less. "Why is this slow?" answers increasingly live somewhere in the OS.
  • How to read it — Start with virtualization. Each chapter is short enough for a commute. End with concurrency and file systems.
  • Trap — Because it's free, "someday" reading is the failure mode. Force yourself through the first three chapters in week one; momentum carries from there.

11. Computer Systems: A Programmer's Perspective (CSAPP, 3rd ed.)

  • Authors — Randal E. Bryant, David R. O'Hallaron.
  • What it teaches — Hardware, OS, and networking from a programmer's point of view. Bits and bytes, the memory hierarchy, caches, virtual memory, system calls, networking. The Carnegie Mellon intro systems textbook.
  • Who should read it — Anyone interested in systems, performance, or infrastructure. Juniors included.
  • The 2026 reason — The 3rd edition (2015) is still the standard. In 2026, AI training and inference are essentially hardware-efficiency problems: you can't run GPU clusters without caches, pages, and memory bandwidth in your head. CSAPP builds that foundation. CMU also publishes free lectures (15-213/15-513) which pair beautifully with the text.
  • How to read it — Chapters 2 (data representation), 3 (machine-level), 6 (memory hierarchy), 9 (virtual memory) are required. 11, 12 (networking, concurrency) are optional.
  • Trap — Heavy. Trying to read cover-to-cover burns out most readers. Pick chapters by need.

12. The C Programming Language (K&R)

  • Authors — Brian W. Kernighan, Dennis M. Ritchie.
  • What it teaches — C itself, and clarity as a virtue. A complete language and its standard library in 250 pages, in disciplined prose.
  • Who should read it — Every developer, especially those who will never write C — to see what a short book at its best looks like.
  • The 2026 reason — First edition 1978, second 1988 — nearly fifty years old. And it's still a model of good technical writing. How tight code can be, how concise documentation can be — in an era when models generate verbose text without limit, K&R's restraint is almost a moral message.
  • How to read it — Chapters 1 and 5 are essential (pointers, arrays). The rest can be skimmed.
  • Trap — This is not the book to learn C for work. It's the book to learn clarity from.

Bonus A · Build a Large Language Model (from Scratch)

  • Author — Sebastian Raschka.
  • What it teaches — Tokenization, attention, transformers, pretraining, fine-tuning, instruction tuning — building an LLM with your hands using only PyTorch and minimal external libraries.
  • Who should read it — ML/AI engineers who use LLMs but want to see inside. Also recommended for application developers who interact with LLMs daily.
  • The 2026 reason — Published 2024. In 2026 LLMs are everyday tools, not OpenAI magic. The debugging and tuning intuitions of someone who has built one once are different from someone who hasn't. With the GitHub companion repo, it's a one-month commitment.
  • How to read it — Follow the GitHub notebooks in order. Train a small GPT yourself.
  • Trap — This is not a "how to use LLMs" book. It's a "how LLMs work" book.

Bonus B · Designing Machine Learning Systems

  • Author — Chip Huyen.
  • What it teaches — The DDIA of ML systems. Data pipelines, features, training, serving, monitoring, data/model drift, ML infra. Not models — systems.
  • Who should read it — Anyone running ML in production.
  • The 2026 reason — Published 2022. Even in the LLM era, the core principles still apply: RAG, fine-tuning, online learning are daily problems, and the question "how does this model live in production?" only matters more.
  • How to read it — Chapters 1, 2, 8, 9 first. Sketch system diagrams as you go, more than copying code.
  • Trap — Huyen's follow-up (AI Engineering, 2024) is also good, but this is the foundation. Read this first.

Bonus section · Essays and papers that became book-equivalent

When twelve books feels like too many, sometimes one essay replaces one book. A short list of essays and papers that carry book-level density.

Joel Spolsky — Joel on Software

  • The Joel Test (2000) — Twelve questions to measure team engineering maturity. More than half are still valid in 2026.
  • The Law of Leaky Abstractions (2002) — Every abstraction leaks; not knowing that hurts more.
  • Things You Should Never Do, Part I (2000) — Don't rewrite from scratch. Every "let's rewrite it" advocate should read this once.

Steve Yegge

  • Practical Magic (2007) — Among the most human writing about abstraction.
  • Have You Ever Legalized Marijuana? / Get That Job at Google — Honest writing about interviews and careers; ages well.
  • Notes from the Mystery Machine Bus — The conservative/liberal programmer taxonomy. Once read, never forgotten.

Dijkstra's EWDs

  • EWD 1036 — On the Cruelty of Really Teaching Computer Science (1988) — Why teaching CS is closer to cruelty than mercy. Short, brutal, correct.
  • EWD 215 — A Case against the GOTO Statement (1968) — A single letter changed the industry's code style.

Paul Graham

  • Beating the Averages (2003) — A Lisp story on the surface; really about tool choice and distance from the mean.
  • Maker's Schedule, Manager's Schedule (2009) — The best essay about calendar violence ever written.

Hamming — You and Your Research (1986)

  • "Why do some people do great research and others don't?" Hamming's Bell Labs talk. Every senior should hear it once.

Bret Victor

  • Up and Down the Ladder of Abstraction (2011) — An interactive essay. Shows abstraction levels as a medium.
  • Inventing on Principle (2012) — Quoted as often as a paper. On the principles of tool-makers.

Lamport — Time, Clocks, and the Ordering of Events (1978)

  • The origin of distributed-systems time. Short, hard, beautiful. Walking through it once is worth a month of half-reads.

When a book feels too far away, read one of these essays. One essay can shift a week.

A suggested reading order

The point isn't to finish all twelve; it's to have a starting point.

0–2 years of experience

  1. The Pragmatic Programmer — professional ethics, foundation.
  2. Code (Petzold) — the abstraction-stack map.
  3. The Mythical Man-Month — truth about teams and schedules.
  4. K&R — clarity, as a standard.

A year for these. Your vocabulary and worldview will grow.

2–5 years

  1. A Philosophy of Software Design — module-design instincts.
  2. Refactoring — keeping code changeable.
  3. Crafting Interpreters — removing the fear of compilers.
  4. OSTEP — OS intuition.

One to two more years. Depth begins to grow.

5–10 years

  1. DDIA — the common vocabulary of distributed systems.
  2. CSAPP — vision that descends to hardware.
  3. Software Engineering at Google — the politics of large codebases.
  4. SICP — the mountain hike, taken once cover to cover.

ML track

  • Build a Large Language Model (from Scratch) — LLMs by hand.
  • Designing Machine Learning Systems — ML system principles.

The "order" is a soft guide. If your work pushed you into distributed systems in year two, go to DDIA. Work tends to pull you to the right book.

Small techniques for reading well

These twelve books are mostly thick or hard. A few small techniques.

1. Skim is one-third, deep is one-tenth

For a thick technical book, reading one third deeply counts as reading it. Deep reading is more like one tenth. The most common failure is trying to deep-read the whole thing.

2. One note per chapter

For each chapter, leave a single one-sentence note: "this chapter says X." A whole book in thirty sentences is a well-read book.

3. Type the code by hand

Especially for SICP, Crafting Interpreters, OSTEP, CSAPP, LLM from Scratch — type the code yourself. The retention difference between a read chapter and a typed chapter is roughly 5x.

4. Group study is powerful

A one-year book club at work pulls books that would otherwise sit on a shelf all the way through. DDIA, CSAPP, SICP especially shine in groups.

5. The exercises are the book

For some books, the exercises teach more than the prose: SICP, CSAPP, OSTEP, LLM from Scratch. Skipping them is reading half the book.

Common traps

  • The shelf grows; your head doesn't. "I'll get to it someday" fills the shelf and not your head. Buy fewer books, finish more.
  • Trend-chasing. A new must-read tweet appears every week. If it's not in this twelve, you can defer it. Classics stay where they are five years from now.
  • Translation vs. original. Well-translated books are faster in your native language. K&R, Mythical Man-Month, Pragmatic Programmer translate well in many languages. SICP, DDIA, CSAPP are usually better in English (or via free official PDFs).
  • Free, therefore unread. OSTEP and Crafting Interpreters keep getting deferred because they're free. Force the first three chapters in week one.
  • Read and not applied. If you can't apply at least one principle from a book to your codebase, the book is not in your head.

Epilogue — Keeping only the essence

In an era when AI improves every day, telling people to read books can sound like swimming upstream. It's the opposite. The better models get, the more what remains in your head should be the essence. Books grow that essence better than anything else.

This essay doesn't command you to finish all twelve. It invites you to start with one that fits your current seat. Year 1–2: The Pragmatic Programmer. Year 3–5: A Philosophy of Software Design. Year 5–10: DDIA. Finishing one makes the next book a natural choice.

Reading takes time. But in the age where models write code, you have more of that time now. Where you used to spend five hours typing code, you now spend one hour coding, two hours reviewing, and two hours thinking. Where does the material for that "thinking" come from? It grows best in books.

The 12-book checklist

Check off as you finish.

  • SICP — cover to cover, once.
  • The Pragmatic Programmer — a full read once a year.
  • DDIA — chapter by chapter, even if slow.
  • Code (Petzold) — once.
  • Crafting Interpreters — it's free; finish it.
  • The Mythical Man-Month — one week.
  • A Philosophy of Software Design — 200 pages.
  • Software Engineering at Google — the chapters you need.
  • Refactoring — within arm's reach for reviews.
  • OSTEP — free; first three chapters.
  • CSAPP — memory hierarchy first.
  • K&R — to learn clarity.

Coming next

  • "Open-source contribution guide — from first PR to maintainer" — the best way to apply what books teach to a real codebase.
  • "Developers as writers — building an audience with blog, newsletter, and docs." The reverse side of reading.
  • "The developer's next career in the AI era — builder, not coder." Where to spend the judgment that books have strengthened.

This essay is one chapter of that broader series.

References

Books — official pages and publishers

Essays and talks

Free courses and videos (appendix)

"The biggest reward of reading a classic isn't the book itself — it's the judgment you carry on the other side of it."

— The Developer's Bookshelf 2026, end.