Sean Campbell

A learning roadmap · in progress

Building engineering judgment

Follow along with what I'm doing and the resources I'm using to become better at decision making & problem solving as a Software Engineer. Building everything out in the open for anyone to see.

Ramp week · Foundations ramp →

Build 0/98 stages · 0/5 courses · 0/8 logs
Reading 0/38 chapters · 0/4 books
Foundations 0/22 items

Build

CodeCrafters, in order
  1. Redis 0 of 4 checkpoints , planned
  2. SQLite 0 of 1 checkpoint , planned
  3. HTTP server 0 of 3 checkpoints , planned
  4. DNS server 0 of 1 checkpoint , planned
  5. Kafka 0 of 5 checkpoints , planned

Reading

anchor + light
  1. Designing Data-Intensive Applications 0 of 12 chapters , in progress
  2. A Philosophy of Software Design 0 of 5 chapters , in progress
  3. Operating Systems: Three Easy Pieces 0 of 7 chapters , planned
  4. Database Internals 0 of 14 chapters , planned

Foundations

NeetCode
  1. NeetCode 150, pattern by pattern 0 of 18 done , in progress
  2. Courses 0 of 4 done , in progress
now · Ramp week
  1. Designing Data-Intensive Applications 0 of 12 chapters , in progress
  2. A Philosophy of Software Design 0 of 5 chapters , in progress
  3. Courses 0 of 4 done , in progress
  4. NeetCode 150, pattern by pattern 0 of 18 done , in progress
  5. now · Sep 19, 2026 · Ramp week
  6. Redis 0 of 4 checkpoints , planned
  7. Operating Systems: Three Easy Pieces 0 of 7 chapters , planned
  8. SQLite 0 of 1 checkpoint , planned
  9. Database Internals 0 of 14 chapters , planned
  10. HTTP server 0 of 3 checkpoints , planned
  11. DNS server 0 of 1 checkpoint , planned
  12. Kafka 0 of 5 checkpoints , planned

Build, planned · M1

Redis

Build a Redis server from raw sockets to replication — defend choosing an in-memory store over disk, and name exactly when that choice breaks.

– · 0%

Reading · M1 · Storage

Designing Data-Intensive Applications

  • 3. Storage and Retrievallog-structured hash indexes
  • 5. Replication

Operating Systems: Three Easy Pieces

  • P1. Persistence — I/O devices & disksalongside RDB/AOF
  • P2. Persistence — files & directoriesalongside RDB/AOF
  • P3. Persistence — crash consistency (fsck/journaling)alongside RDB/AOF
  • P4. Persistence — log-structured file systemsalongside RDB/AOF
  • C1. Concurrency — threads & locksalongside replication
  • C2. Concurrency — condition variables & semaphoresalongside replication
  • C3. Concurrency — common bugs & deadlockalongside replication

A Philosophy of Software Design

  • 4–6. Modules should be deeplight read

Foundations · M1 · Storage

Courses

  • Algorithms & Data Structures for Beginners35 lessons·finish it
  • Core Skills — implement the data structures20 lessons

NeetCode 150, pattern by pattern

  • Arrays & Hashing9 problems·Redis hash store
  • Two Pointers5 problems
  • Sliding Window6 problems
  • Stack7 problems
  • Linked List11 problems
“RESP vs JSON for a wire protocol: what Redis traded away, and the workload where I’d make the opposite call.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“RDB vs AOF: the durability/latency/recovery trade I’d default to, and the workload that flips it.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“Single-leader vs multi-leader: where I draw the line, and what each costs.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · M2

SQLite

Read a real SQLite database by hand — page headers, the B-tree, an indexed query — and predict which storage engine wins a query pattern before benchmarking.

– · 0%

Reading · M2 · Engines

Designing Data-Intensive Applications

  • 2. Data Models and Query Languages
  • 3. Storage and Retrievaldeep — B-trees vs LSM-trees

Database Internals

  • 1. Introduction and Overviewthe exact match for this build
  • 2. B-Tree Basics
  • 3. File Formats
  • 4. Implementing B-Trees

Foundations · M2 · Engines

NeetCode 150, pattern by pattern

  • Binary Search7 problems·SQLite B-tree
  • Trees15 problems·SQLite B-tree
  • Tries3 problems
“B-tree vs LSM for this workload: which I’d reach for, and the read/write ratio that flips the call.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · M3

HTTP server

Build an HTTP/1.1 server — requests, responses, headers, compression, keep-alive — and reason about encoding and evolution on the wire.

– · 0%

Reading · M3 · Encoding

Designing Data-Intensive Applications

  • 4. Encoding and EvolutionJSON, Protobuf, Avro, schema migrations

Database Internals

  • 5. Transaction Processing and Recoverytrailing read
  • 6. B-Tree Variantstrailing read
  • 7. Log-Structured Storagetrailing read

A Philosophy of Software Design

  • 7–10. Information hiding & general-purpose designlight read

Foundations · M3 · Encoding

NeetCode 150, pattern by pattern

  • Heap / Priority Queue7 problems
  • Backtracking9 problems
“Versioning an API without breaking last year’s clients — the migration I’d never ship.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · M4

DNS server

Build a DNS server — construct and parse the binary packet format, handle name compression, forward queries — and appreciate compact wire encoding.

– · 0%

Reading · M4 · The packet

Designing Data-Intensive Applications

  • 6. Partitioningsets up M5

A Philosophy of Software Design

  • 11–16. Comments & naminglight read

Foundations · M4 · The packet

NeetCode 150, pattern by pattern

  • Greedy8 problems
  • Intervals6 problems
“Compact binary protocols: where DNS’s choices (name compression, UDP) pay off and where they bite.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · M5

Kafka

Build a Kafka broker — the partitioned log, offsets, fetch and produce — and name the consistency model a system needs versus the one it secretly relies on.

– · 0%

Reading · M5 · Consensus

Designing Data-Intensive Applications

  • 7. Transactions
  • 8. The Trouble with Distributed Systems
  • 9. Consistency and Consensus

Database Internals

  • 8. Introduction and Overview (Distributed)the distributed half begins
  • 9. Failure Detection
  • 10. Leader Election
  • 11. Replication and Consistency
  • 12. Anti-Entropy and Dissemination
  • 13. Distributed Transactions
  • 14. Consensus

A Philosophy of Software Design

  • 17–21. Consistency, obvious code, trendslight read — finishes the book

Foundations · M5 · Consensus

NeetCode 150, pattern by pattern

  • Graphs13 problems·replication & partitioning
  • Advanced Graphs6 problems
  • 1-D Dynamic Programming12 problems
  • 2-D Dynamic Programming11 problems

Reading · Capstone

Designing Data-Intensive Applications

  • 10. Batch Processing
  • 11. Stream Processing
  • 12. The Future of Data Systemsfinishes DDIA

Foundations · Capstone

NeetCode 150, pattern by pattern

  • Math & Geometry8 problems
  • Bit Manipulation7 problems

Courses

  • Advanced Algorithms (optional, later)35 lessons
“Which consistency model a feature needs — and the one it’s secretly relying on.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“Capstone: a published system-design writeup distilled from these decision logs.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Reading, in progress

Designing Data-Intensive Applications

Martin Kleppmann

– · 0/12

Close

Reading, planned

Database Internals

Alex Petrov

– · 0/14

Close

Reading, planned

Operating Systems: Three Easy Pieces free

Remzi & Andrea Arpaci-Dusseau — Concurrency + Persistence parts only

– · 0/7

Close

Reading, in progress

A Philosophy of Software Design

John Ousterhout

– · 0/5

Close

Foundations, in progress

Courses

–

Close

Foundations, in progress

NeetCode 150, pattern by pattern

–

Close

Progress is shared — what you see is the live, saved state. The owner can unlock edit mode to check items off.