There is a specific kind of frustration that only developers recognize: finishing a course, getting the certificate, and then opening a blank file and having nothing come. You know the syntax. You recognize the patterns. But the moment the scaffolding is removed, the knowledge evaporates. "Build Your Own X" — one of the most starred repositories on all of GitHub — is a direct response to that failure mode, and it works in a way that almost no structured course does.
For developers who are tired of finishing courses and still not being able to build anything real.
Table of Contents
- 1. The Problem With How Most Developers Learn
- 2. What "Build Your Own X" Actually Is
- 3. Why It Has More Stars Than Most Frameworks
- 4. The Uncomfortable Truth About Abstraction
- 5. What You Actually Learn in Each Section
- 5.1 Neural Networks: Removing the Mystery
- 5.2 Blockchain: Finally Understanding What the Hype Is About
- 5.3 Databases: The Section That Makes Every Query Make Sense
- 5.4 Compilers and Interpreters: The Most Transferable Deep Dive
- 5.5 Operating Systems: Demanding and Worth Every Hour
- 5.6 Bots and Automation: The Beginner-Friendly Entry Point
- 5.7 Networking: Where Theory Finally Becomes Real
- 6. The Real Reason This Repository Changes How You Think
- 7. How It Compares to Courses, Bootcamps, and Degrees
- 8. What Kind of Developer Should Use It — and How
- 9. The Mistakes That Will Waste Your Time
- 10. A Learning Path That Actually Works
- 11. Why "Build It Yourself" Matters More Than Ever in the AI Era
- 12. Where to Start Right Now
1. The Problem With How Most Developers Learn
You find a course. It has good reviews, a clean interface, and a calm instructor voice that walks you through every concept with careful scaffolding. You follow along. Things make sense. You finish the course, maybe even get the certificate, and feel genuinely good about what you have accomplished.
Then you open a blank file and try to build something from scratch. Nothing comes. You know the syntax. You recognize the patterns. But the moment the hand-holding is removed, you are lost. You end up going back to the course, copying code you do not really understand, or searching for answers without a clear sense of why the solutions you find actually work.
This is not a personal failure. It is the predictable result of a particular style of learning: passive, guided, scaffolded from start to finish, optimized for the feeling of progress rather than the substance of it. Your brain is excellent at recognizing things it has seen before. A course exploits that. It makes unfamiliar material feel familiar just quickly enough that you believe you understand it. But familiarity is not understanding, and recognition is not capability.
The antidote has been known for a long time. You learn by doing — more specifically, by struggling through something hard and finishing it. Every developer who has built a real project, not a tutorial project, knows this intuitively. The project teaches you in a week what a year of courses cannot.
"Build Your Own X," available at github.com/codecrafters-io/build-your-own-x, is one of the most thoughtful attempts to systematize that kind of learning the open source community has produced. It is not a course. It is not a platform. It is a curated map to some of the best "build it from scratch" tutorials ever written, organized by technology domain, available for free, and maintained by a community of developers who take the project seriously.
2. What "Build Your Own X" Actually Is
Every entry in the repository is a tutorial for building something that already exists — not a tutorial for using it. Instead of learning how to write a database query, you learn how to write a database. Instead of calling a neural network API, you implement backpropagation by hand. Instead of configuring a web server, you build one using raw sockets.
The X in "Build Your Own X" is a placeholder for things like SQLite, Git, Redis, Docker, a Python interpreter, a TCP stack, a shell, a regex engine, and dozens of other technologies that most working developers treat as black boxes. The repository is organized into categories covering:
- 3D renderers and augmented reality systems
- BitTorrent clients and blockchain implementations
- Bots, command-line tools, and automation systems
- Databases and Docker-like container systems
- Emulators, virtual machines, and front-end frameworks
- Git, version control systems, and network stacks
- Neural networks, operating systems, and physics engines
- Programming languages, regex engines, search engines, and web servers
Each category links to multiple tutorials — usually long-form write-ups or annotated repositories. Tutorials target different programming languages, so developers working in Python, Rust, Go, or C can generally find relevant material in the same category. What separates this from a bookmark folder is curation: the maintainers are selective. A tutorial gets included because it genuinely teaches structural understanding, not because it produces a working demo as quickly as possible.
3. Why It Has More Stars Than Most Frameworks
"Build Your Own X" regularly appears among the most starred repositories on GitHub. That is notable company — most repositories at that tier are frameworks and tools that millions of developers depend on in production. This repository does not help you ship faster. It does not give you a library to install. It is a list of links. And it has accumulated more stars than most of the software the industry actually runs on.
The reason is that it fills a gap that almost nothing else fills. The internet has no shortage of tutorials for using technologies. Tutorials for building those technologies from scratch are scattered, hard to find, and wildly variable in quality. This repository aggregates the best of them, filters the mediocre ones, and organizes them clearly enough that finding a starting point takes about five minutes.
There is also something that resonates about the repository's premise at a professional level. Most developers carry a low-level awareness of the systems beneath their abstractions — databases, compilers, operating systems, networking stacks — that they understand well enough to use but not well enough to reason about when something goes wrong. "Build Your Own X" addresses that gap directly. It says: someone built this and documented every step. Here is where to start.
4. The Uncomfortable Truth About Abstraction
Modern software development is built on abstraction. You call a function and something happens. You do not need to know what. The function was written by someone else, tested by someone else, and optimized by someone else. Your job is to compose these abstractions into something useful — and this is genuinely good. Abstraction is what makes large-scale software development possible.
But abstraction has a shadow side: it makes developers fragile at the boundaries. Most bugs that are genuinely hard to diagnose happen exactly there. When your ORM generates a query that scans the full table, when your async framework deadlocks under specific conditions, when your container runs out of file descriptors, when your query plan stops using the index for reasons you cannot explain — these are all failures at abstraction boundaries. Developers who have never looked beneath those boundaries are effectively unable to reason toward a solution when this happens.
Developers who have built a database from scratch can reason about query performance at a mechanistic level. They know what a full table scan means in terms of disk reads. They understand why a particular index does or does not help. They can form a hypothesis from first principles rather than guessing.
This is the core value of "Build Your Own X." Not that you will ever deploy your toy operating system or hand-rolled database engine. But that having built them changes the mental model you bring to every problem that touches those domains. Once you have built a B-tree and watched how it rebalances, you cannot un-know how databases index data. That knowledge becomes structural and permanent.
5. What You Actually Learn in Each Section
5.1 Neural Networks: Removing the Mystery
Building a neural network from scratch eliminates the mythology that surrounds AI in most introductory treatments. Here is what you actually implement: a function that takes an input vector, multiplies it by a matrix of weights, adds a bias vector, and passes the result through a non-linear activation function. That is one layer. A neural network is this operation repeated several times in sequence.
You implement forward propagation — feeding input through all layers to get a prediction. You implement error calculation — how wrong was the prediction? You implement backpropagation — the algorithm that uses the chain rule from calculus to calculate how much each weight contributed to the error. Then gradient descent — adjusting each weight slightly in the direction that reduces error.
None of this requires a machine learning library. Most good introductory implementations use only NumPy for matrix operations. What is powerful about doing this manually is that every subsequent question about neural network behavior has a mechanistic answer you can reason toward — not one you need to look up.
5.2 Blockchain: Finally Understanding What the Hype Is About
Building your own blockchain is one of the more clarifying exercises in the repository. You start with the data structure: a block containing a list of transactions, a timestamp, a reference to the previous block's hash, and a nonce. The hash of each block is computed from all of these fields together — change anything in a previous block and its hash changes, breaking every subsequent link. Tamper-evidence stops being an abstract claim and becomes something you understand mechanically.
You then implement proof-of-work: a valid block must have a hash beginning with a certain number of zero bits. The only way to produce such a hash is to keep incrementing the nonce until you get lucky. This computational effort is the mechanism by which the network makes rewriting history expensive. You then implement Nakamoto consensus — nodes accept the longest valid chain — and understand both why it works and what its actual security guarantees are: probabilistic, not absolute, and dependent on no single party controlling more than half the network's computational power.
5.3 Databases: The Section That Makes Every Query Make Sense
Databases are arguably the highest-leverage topic in the repository for working developers. Almost everyone uses one. Almost no one understands how it works. The gap has real, daily costs.
The tutorials typically start with a persistent key-value store — a file of key-value pairs with basic read and write operations. This immediately raises questions you must answer: How do you find a key without reading the entire file? How do you handle a write that crashes halfway through? These questions lead directly to the central data structures of every real database.
You implement a B-tree index and immediately understand why databases can answer point and range queries efficiently, and why updating an index adds overhead to every write. You implement a write-ahead log and understand durability — the D in ACID — and what it costs. You implement transactions, confront concurrent writes, implement locking, watch it create deadlocks, and understand why isolation levels exist as explicit trade-offs between correctness and performance. Developers who complete this section report a specific, lasting change: they stop writing queries by feel and start writing them with a clear model of what the database engine will actually do.
5.4 Compilers and Interpreters: The Most Transferable Deep Dive
Most developers will never write a production compiler. But the concepts engaged in building one appear constantly across software engineering. You start with a lexer that groups a character stream into tokens — keywords, identifiers, operators — essentially a state machine over character sequences. State machines appear in nearly every domain of software.
You implement a parser that produces an abstract syntax tree — the data structure behind every linting tool, editor plugin, and code transformation library you have used without knowing how it worked. You implement semantic analysis and either code generation or an interpreter that walks the tree and executes it directly. The transfers are immediate: configuration parsers are lexers and parsers; every linting rule operates on an AST; every template engine parses a grammar. Once you have built these things, you can read the source code of these tools with structural comprehension rather than behavioral guessing.
5.5 Operating Systems: Demanding and Worth Every Hour
The OS tutorials are the most demanding entries in the repository. You start before the OS itself — writing a boot loader that lives in the first sector of a bootable disk, working without a standard library, without an operating system, without any of the scaffolding application development takes for granted.
You implement a memory allocator, immediately face fragmentation, and understand why garbage collectors and allocators are non-trivial engineering challenges. You implement a process scheduler — the mechanism behind the illusion of concurrent execution on a single CPU core — by implementing a timer interrupt and a context switch. You implement system calls and understand why programs cannot write directly to disk: the kernel mediates hardware access, enforcing isolation between processes.
Your toy OS will not run any real software. That is not the point. Every time you encounter "kernel panic," "page fault," or "context switch" in a log after this, you will have a structural understanding of what it means.
5.6 Bots and Automation: The Beginner-Friendly Entry Point
If you are earlier in your programming journey, the bot tutorials are one of the best places to start. Building a Discord or Telegram bot requires working with an event-driven model — your program starts, connects to a server via a persistent WebSocket connection, and waits. When an event arrives, your handler runs. This is the fundamental architecture of most networked applications, and experiencing it through a bot is far easier than absorbing it from a description.
You handle authentication, rate limiting, and state management — concerns that map directly onto building web services and any networked application. The bot makes the feedback loop fast and satisfying, which keeps you engaged long enough to absorb the patterns.
5.7 Networking: Where Theory Finally Becomes Real
The HTTP server exercise is one of the best intermediate projects in the repository. HTTP is a text protocol — requests and responses are formatted strings sent over TCP connections. You read bytes from a socket, parse request lines and headers, route the request to a handler function, construct a response with the right status code and headers, and write the bytes back. This exercise makes visible everything that Express, FastAPI, Django, and every web framework hides from you. The router is a lookup table from URL patterns to handler functions. The middleware is a chain of functions that transform the request and response around the handler. Once you understand this, you can read framework source code with comprehension instead of confusion.
6. The Real Reason This Repository Changes How You Think
There is a pattern that developers who have worked through several of these tutorials describe consistently. It is not just that they know more facts. It is that they think differently. When they encounter an unfamiliar technology, their first instinct is to wonder how it works — not just what it does. When they hit a bug they cannot explain, they can reason toward a hypothesis from first principles rather than only from patterns they have seen before.
This shift is the actual return on investment. The specific system you build is not the valuable thing. The change in how your brain models software is. And that change does not happen from reading about building things. It happens from the specific combination of building something with real complexity, getting stuck, figuring out why, and finishing. The struggle is not a side effect of the learning. It is the mechanism of the learning. Cognitive science calls this desirable difficulty — the friction that makes learning feel hard in the moment is the same friction that makes the learning stick.
7. How It Compares to Courses, Bootcamps, and Degrees
Courses, bootcamps, and degrees have genuine value. A formal CS degree gives you mathematical foundations — algorithms, complexity theory, formal language theory — that are genuinely difficult to absorb informally. A bootcamp can take someone from no programming background to employable junior developer faster than any alternative. Online courses provide structured access to expert instruction at very low cost.
But all of these formats share a structural weakness: they are optimized for getting you through the material, not for ensuring you understand it deeply. They test you on things you have seen before. They scaffold you so thoroughly that you never experience the full cognitive load of building something from scratch without help.
| Format | Strengths | Core Limitation |
|---|---|---|
| University CS Degree | Mathematical foundations, algorithms, theory | Limited practical, production-context exposure |
| Bootcamp | Fast path to employability; structured and intensive | Breadth over depth; little time for foundations |
| Online Course | Accessible, affordable, expert instruction | Passive; optimized for completion, not understanding |
| Build Your Own X | Forces genuine understanding; permanent mental models | Requires self-direction; slow; demands prior baseline |
The honest comparison is not "this repository instead of a course." It is "this repository in addition to whatever foundation you already have." Think of formal education as the map and project-based learning as the territory. Most developers have spent far too much time with the map and far too little time in the territory.
8. What Kind of Developer Should Use It — and How
Still Learning the Basics
If you are still working on basic syntax, control flow, and data structures, the more advanced sections will be more frustrating than instructive. That said, the bot tutorials and simpler game tutorials are genuinely accessible to developers a few months into their learning. Pick one in a language you are actively learning and treat it as your first real project. Finish one thing before coming back.
You Can Build Things but Don't Know How They Work
This is the sweet spot. If you have been writing code for one to four years, can build functional applications, and feel the nagging sense that you do not understand the systems beneath your abstractions — this repository was built for you. Pick the technology closest to what you work with every day. Proximity to your daily work means every insight has an immediate application, which makes the knowledge far more likely to stick.
Building a Product and Hitting Unexplainable Problems
Developers building their own products often reach a point where their system behaves in ways they cannot explain — the database is slow for reasons they cannot diagnose, the server drops connections under load. Often the root cause is building on systems they understand well enough to use but not well enough to diagnose. The database tutorial specifically addresses this. Understanding what a B-tree index is and when it gets used — mechanistically, not conceptually — translates directly into diagnosing and fixing performance problems in production.
Preparing for a Technical Interview
Senior engineering interviews test two things: system design judgment and depth of CS fundamentals. Both are well served here. For system design, the database, distributed systems, and OS sections give you first-hand experience with the trade-offs that appear in almost every design question. One important caveat: do not use this as a two-week cram tool. The learning is slow and requires genuine engagement. Start at least two to three months in advance.
Months 1–2: Pick the topic closest to your current daily work. Databases if you use SQL regularly. Neural networks if you work in ML. HTTP server if you build APIs. Relevance accelerates retention.
During the tutorial: Work in sessions of at least 90 minutes. Type the code — do not paste it. Being stuck is the correct state. Re-read the relevant section, form a hypothesis, try again before copying anything.
After finishing: Break what you built. Add one feature the tutorial did not include. Write a short explanation of what you built and why the key design decisions were made. This post-tutorial phase is where "I followed the steps" becomes "I understand the system."
Month 3+: Wait at least a week before starting a second tutorial. Let the first set of ideas settle and connect with your existing knowledge.
9. The Mistakes That Will Waste Your Time
The most common mistake is opening the repository, feeling excited, and immediately trying to do five things at once. You start a neural network tutorial. An hour later you are reading about blockchains. Two weeks later you have not finished anything and the initial excitement has faded into guilt. The value of this repository is not in browsing it. It is in finishing one thing deeply. Pick one tutorial and do not open another section until you have genuinely completed what you chose — code runs, you understand why it runs, and you could explain the key design decisions to someone else.
The second mistake is reading the tutorials instead of doing them. Every tutorial in this repository is designed to be followed with a code editor open. If you are reading it like a blog post, you are not learning. Type the code — not paste it. Make the mistakes that come from typing. Debug them. The friction is the mechanism.
The third mistake is finishing the tutorial and immediately moving on. A tutorial gives you a working starting point, not full understanding. After finishing, break what you built. Add a feature the tutorial did not include. Try to handle edge cases it skipped. The post-tutorial extension phase is where real understanding consolidates.
The fourth mistake is choosing a tutorial in an unfamiliar language because the language looks exciting. If you do not know Rust well, building a database in Rust is a worse learning experience than building one in Python. You will spend your entire cognitive budget on the language, leaving none for the system. Use a language you already know well. The system is the lesson.
10. A Learning Path That Actually Works
Start by spending thirty focused minutes browsing the repository and making a shortlist of three topics that genuinely interest you — not topics you think you should learn, but topics you are actually curious about. Motivation matters for this kind of slow, sustained work in a way it does not matter for quick tutorials.
From your shortlist, pick the one most relevant to your current work or goals. Before writing a single line of code, read through the entire tutorial once for orientation. Most people skip this and feel lost two-thirds of the way through when a concept introduced early becomes important. One read-through saves multiple frustrating hours later.
When you finish the main tutorial, write down three specific things it did not fully explain that you still want to understand. Spend time on those gaps. Then write something about what you built — a personal blog post, a GitHub README with a real explanation. The act of writing forces you to consolidate and articulate your understanding in a way that reveals both what you know and what you only think you know. It is one of the most effective learning consolidation tools available, and almost nobody does it.
11. Why "Build It Yourself" Matters More Than Ever in the AI Era
AI coding tools are getting better, quickly. They can already generate significant quantities of production-quality code from natural language descriptions. This raises a direct question for working developers: what remains valuable about deep technical knowledge when AI can produce working code?
The answer, at least for the foreseeable future, is almost everything that matters at senior levels. AI tools are very good at producing code that matches familiar patterns. They are much weaker at diagnosing novel failures, making trade-off decisions in system design, reasoning about the behavior of a complex system under unusual conditions, or recognizing when working code is subtly wrong in a way that will only manifest at scale.
These are also exactly the capabilities that "Build Your Own X" develops. A developer who has built a database engine from scratch brings a quality of reasoning to database performance problems that no AI tool currently replicates. Deep technical knowledge is also what allows you to direct AI tools effectively — developers who understand what they are asking for can evaluate what they receive, catch problems before they ship, and write precise prompts rather than vague ones that produce code they cannot verify.
The "Build Your Own X" philosophy — understand by building, from scratch, with real struggle — produces exactly the developer who will be most effective as AI handles more of the routine work. It is not a retro exercise in doing things the hard way. It is preparation for a world where deep understanding is the remaining comparative advantage of the human engineer. For more on how this shift is playing out in professional development contexts, see our breakdown of what happens to developers as AI takes on more of the coding work.
12. Where to Start Right Now
The repository is at github.com/codecrafters-io/build-your-own-x. It is free, updated regularly, and organized clearly enough that you can find a relevant tutorial in about five minutes of browsing. Four starting points based on where you are:
- Early developer (a few months of experience): Look at the bot or game sections. Pick a tutorial in the language you are currently learning. Plan for ten to fifteen hours of implementation time. Finish one thing before coming back.
- Working with databases daily: Start with the database section. Look for SQLite-inspired or Redis-inspired tutorials depending on which is closer to your work. Give it a month of focused sessions. The change in how you write and debug queries afterward is concrete and immediate.
- Want to understand AI mechanistically: Start with the neural network section and choose a Python tutorial. Plan for around twenty hours of honest implementation time, more if you extend beyond the tutorial.
- Preparing for senior engineering interviews: The compiler, database, and distributed systems sections are the highest-value investments. Start three months out, not three weeks. Use the time you save on not cramming to actually understand something.
There is one thing to avoid above everything else: spending more time reading about this repository than working through it. Everything you genuinely understand about software, you will have built yourself, one way or another. The repository makes that process a little more deliberate, and a lot less lonely.
→ The AI GitHub Repositories Developers Are Rushing to in 2026