hacker tutorialscourse catalogue

Courses / Course 06 · Tools · opening stages, more coming

Build your own developer tools

You end up withA terminal text editor in about 1,000 lines of C, with search and syntax highlighting; a Git in about 1,000 lines of Python that can init, add, commit, log, checkout and tag, compatible with real Git repositories; and a Redis-like server in C with an event loop, hashtables, sorted sets and key expiry.

  • 8 sources
  • 66 HN threads
  • 9,234 points
  • 2015–2026
  • 6–10 weeks part-time for the opening stages

Data pulled 2026-11-08 · time estimates are editorial

Why rebuild tools you already use every day? Because they stop being magic. After this track, a terminal is a byte stream you can drive with escape codes, a Git repository is a folder of compressed objects you can read by hand, and Redis is an event loop around a hashtable. When the tool misbehaves, you know which layer to look at. Hacker News has voted these tutorials up since 2015. Every step below shows its HN score and quotes what HN said.

This course is an opener. Its first three stages are published. Containers and a debugger come next; see Coming next at the end.

How to read the receipts.

  • Points are summed across every HN submission of the same URL.
  • “Submitted N×” means HN rediscovered it N times.
  • Quotes come from the highest-ranked top-level comments in those threads, and a quote is sometimes a criticism. Quotes keep the commenter’s spelling.
  • Steps are ordered for learning, not by points.
  • Times are our estimates, not the authors’. They assume evenings and weekends, and a reader who writes some C and some Python.

One piece of advice from HN applies to every step:

HN eterevsky, 2022 · comment

“One advice: for any of these topics take a tutorial directed at language X and implement the solution in language Y. This will prevent you from mindlessly copying the code and will force you to understand what you are doing.”

Stage 11–2 weeksA text editor

1.

Build Your Own Text Editor (viewsourcecode.org) · Paige Ruten

2,577 points, submitted 15× (2017–2025) · Free · C · ~1–2 weeks

A booklet that rebuilds antirez’s kilo editor in 184 small steps: raw terminal mode, reading keys, drawing the screen with VT100 escape codes, a row buffer, editing, saving, incremental search and syntax highlighting. About 1,000 lines of C in one file, no libraries, not even curses. You can compile and run after almost every step.

HN frogfish, 2019 · comment

“What I instantly liked is, how literally it starts from scratch and builds a couple of lines at a time.”

HN Dangeranger, 2017 · comment

“Reference implementations of medium sized applications are incredibly useful for leveling up as a programmer.”

Read alongside: antirez’s own post on writing the original, Writing an editor in less than 1000 lines of code, just for fun (773 points, submitted 8×), and his source. “Reading through this code is a veritable rite of passage. You learn how C works, how text editors work, how VT codes work, how syntax highlighting works, how find works, and how little code it really takes to make anything when you strip away almost all conveniences, edge cases, and error handling.” (90s_dev, 2025 · comment)

Alternative in Rust: Philipp Flenker’s hecto (155 points) rebuilds the same editor in about 3,000 lines of Rust. “The step-by-step format using code diffs made everything very clear and easy to follow along.” (mblode, 2021 · comment)

Stage 22–3 weeksGit

2.

Git from the inside out (maryrosecook.com) · Mary Rose Cook

1,444 points, submitted 12× (2015–2022) · Free · essay · ~1–2 evenings

Read this before writing any code. It runs a short series of Git commands on one small project and shows, after each, what changed in the .git folder: blobs, trees, commits, refs and the index. By the end you have the model the next step implements.

HN edejong, 2016 · comment

“Certain systems can best be understood as black boxes. You put some commands in and magic happens. Git was not designed to be such a system and early users of git know this.”

3.

Write yourself a Git (wyag.thb.lt) · Thibault Polge

691 points, submitted 5× (2019–2024) · Free · Python · ~2 weeks

Build wyag, a Git that reads and writes real Git repositories, in about 1,000 lines of standard-library Python. You implement init, hash-object, cat-file, log, ls-tree, checkout, show-ref, tag, rev-parse, ls-files, check-ignore, status, rm, add and commit. The author notes that a commit in the tutorial’s own history was made by wyag itself. Check your work by running real git against the repositories your version writes, and the other way round.

HN’s comments point to a paid book that goes further: James Coglan’s Building Git, which also covers diffs, merges and the network protocol (comment).

Alternative: Nikita Leshenko’s ugit (667 points, submitted 4×) builds a Git-like tool in Python one small diff at a time, starting from init, with the code downloadable at every step. “I particularly like the iterated development approach to teaching on this site.” (mixedmath, 2021 · comment)

Stage 33–5 weeksRedis

4.

Build Your Own Redis with C/C++ (build-your-own.org) · James Smith

802 points, submitted 3× (2023) · Free online; paid PDF, EPUB and paperback · C/C++ · ~3–5 weeks

A Redis-like server built up from sockets: a TCP server and client, a request-response protocol, non-blocking IO with an event loop, then the data structures that make Redis fast (a resizable hashtable, a balanced binary tree, sorted sets), timers, key expiry with TTLs and a thread pool. If sockets are new to you, do step 1 of the networking course first; the book itself recommends Beej’s guide.

HN rcarmo, 2023 · comment

“By implementing it, you learn about socket handling, event loop for a specific runtime, threading models, data representation, concurrency (if you want to do a multi-threaded version), etc.”

Coming next

The next stages are chosen and their receipts are pulled, but they are not yet reviewed or written:

  • Containers from scratch. Bocker, Docker in about 100 lines of bash (1,973 points); Linux containers in 500 lines of code (1,116 points); the Rubber Docker workshop (570 points); Linux containers in a few lines of code (458 points).
  • A debugger. Tim Misiak’s Writing a debugger from scratch (583 points) and Sy Brand’s Writing a Linux Debugger (300 points).

The reference shelf

build-your-own-x · https://github.com/codecrafters-io/build-your-own-x · 2,125 points, submitted 17× (2018–2026) · Free. The best-known list of build-it-yourself tutorials, grouped by what you build. Use it to find a next project once this course runs out. “The tutorials listed here can vary a lot in quality.” (p4bl0, 2022 · comment)

Editorial backlog

Checked against HN on 2026-11-08 (candidates_receipts.json), not used:

  • CodeCrafters (1,366 points across 42 submissions): paid, guided “build your own” challenges for Redis, Git, SQLite, Docker and more. Left out because this catalogue lists free paths; a reader who wants tests and structure can use it for any stage here.
  • Pro Git, chapter 10: Git Internals (24 points over 10 submissions): good reference, little HN discussion.
  • How debuggers work (Eli Bendersky, 83 points): a candidate reading for the debugger stage.

Method

  • Candidates came from the 204 tools-tagged stories in the 4,140-story pull, plus a tools topic pull with 30 terms: 240 candidates in all (phase1-stories/data/tools_candidates.json).
  • Selection. 17 resources had receipts pulled; 8 are used here, chosen by hand for followability and sequence. Points were then totalled across every submission of each URL.
  • Quotes come from the top five top-level comments of the two best-scoring threads per resource, in HN’s ranked order via the Firebase API. Links go to the full comment. Every ID and quote is checked with phase1-stories/scripts/check_track.py.
  • Content and costs were checked on 2026-11-08 on each resource’s own page: the kilo booklet’s step count, wyag’s command list and line count, hecto’s size, and the Redis book’s table of contents and free web edition. Time estimates are editorial, not measured.
  • Data: tracks/tools/receipts.json (resources used) and candidates_receipts.json (all 17 checked).