Ask HN: Where do I find good code to read?

In general, have a look at the Standard Template Library or Boost examples directory. Then some unit tests for simple GNU programs similar to what you are building, CLI command source like "ps" for OS interactions, and finally an OS kernel like Linux or *BSD. There are also several online classes offered by linuxfoundation.org etc.

Start with a small SBC like a pi4/BeagleBoard, and learn how to snapshot disk images (you will severely damage things while learning). There are also several open syntax formatting standards published by projects (and companies like Google), that will guide you on the local ecosystem.

Expect a Hazing in some places, as some folks tend to forget they were students once too.

It would also be wise to spend a few days studying security-auditing-tools, as one may learn to mitigate common ways people will try to break stuff. Detection and incident-handling is arguably more important than outright prevention.

Happy coding, =)

1. Busybox. It's basically a collection of common Unix utilities, from common commands like ls or cat, to system daemons like crond and init. It's a good way to learn more about how Linux and other Unix-based systems work under the hood. Busybox applets are pretty independent from each other, so you can just take one and focus on it specifically, digging into the common library code if you need to. The utilities aren't as fully-featured as their GNU coreutils counterparts, which makes it easier to understand what they actually do. Busybox is not a toy project by any means, though, it's used in many embedded devices and leaner Linux distributions, Alpine being the prime example. However, it's written in some pretty dense C, with a fair bit of pointer magic involved, so if you don't understand things like the equivalence between a pointer and the beginning of an array, some things might not make sense.

2. The Go standard library. Unlike many programming languages, Go does not rely on much external code. Whereas Python delegates zip handling to zlib, handling of TLS connections to Openssl and so on, Go just includes all of this in the standard library, and it's all pretty readable Go code. If you want to understand many common algorithms or file formats, everything from sorting arrays to parsing JSON to sending and receiving HTTP requests or common cryptographic operations, all written in a readable style, in a language much higher level than C, just look at the Go stdlib. Go even fully implements everything needed for its own compilation, including linkers and assemblers. I haven't read these parts much, and a lot of that code is transpiled from C, so I can't say how good the code quality is.

3. Serenity OS. It's a hobby Posix-based operating system written in C++, with no external dependencies, not even libc or libstdc++. They have their own homegrown implementations of every part of an operating system, from a monolithic kernel, to common Unix utilities, archive handling, audio and video codecs, common data structures, like vectors (growable arrays), hash maps, locks, mutexes and other concurrency primitives, a custom string implementation, a window server and a GUI library, including a fully-featured event loop system, their own window manager and many common GUI widgets, to actual applications and games. They even have a custom web browser with a custom web engine and JS interpreter. As a rule of thumb, if something it's either in Busybox or in the Go standard library, there's a good chance it will also be in Serenity. Again, their utilities do much less than their non-serenity counterparts and are far less optimized, but that also means there's a lot fewer layers of abstraction to deal with and that the general principles underlying their implementation are actually easier to understand. The fact that everything is in a single repo, neatly organized, written in one language with common conventions, just makes it really pleasant to read. Their code quality isn't always the best, but the fact that it's C++ and not C does make things easier. Even though I haven't actually used the OS (because of accessibility concerns), it's one of these repos that I always have cloned on my computer, and it's the first place I look if I'm curious how a particular feature or app can be implemented.

4. If you're in any way interested in AI, everything written by Andrej Karpathy, notably Micrograd and Nano GPT. There's also Tinygrad, a bigger but still understandable take on Micrograd. Unless you're an expert, you need to watch Andrej's Youtube videos to actually understand the code, but the feeling I got when I actually understood the principle behind Micrograd is one I will never forget. I consider it to be the most beautiful piece of code I've ever seen, it basically embodies the whole principle of what a neural net is in 200 lines of code. Everything else that the big libraries do is basically just implementations of actual models, optimization and glue code, such as for loading data and such. It's often crucial optimization, optimization without which modern neural networks wouldn't be possible at all, but just optimization nonetheless.

5. Everything concerning Elixir, both the standard library, other libraries written in it, as well as open-source Phoenix web apps. Deep down, it's basically a Lisp without the off-putting parentheses. There are a lot of lessons to be learnt there, from the power of macros and the fact that things like "if" can be written in the language itself instead of being a special construct, to the power of pattern matching and the pipeline operator, to the advantages of its concurrency model and functional programming in general.

To generalize beyond these specific examples, if you want to understand something, find a smaller version of it, and try understanding that. The smaller version might just be a git commit from a good few years ago, with much fewer features, but it's better if it is a different, more basic (but preferably not toy) implementation of the same app, feature or algorithm. Don't read V8, PyTorch or Postgres, read Lua, Tinygrad or Sqlite instead.

Beside, "rewrite" here doesn't mean "new repo, new project, new everything" it means reimplementation, usually based on the lessons learned from the previous implementation, and that does include edge case handling, as well as expanded functionality to "underwrite" or justify the effort spent on the rewrite.

I like this and it is true. In addition, I have found that good code also tends to survive refractors despite having the quality of being easy to change.

The Ask HN post specifically mentioned good code but what follows are some (of my subjective) thoughts about the benefits of reading bad code. Bad code is haphazard and varied and good code is “samey”. You are a pattern matcher and this is part of your training. Good code will make more of an impact on your understanding if you have read a lot of bad code beforehand. Being able to read and understand bad code is a far more lucrative skill to have in the workplace than being able to quickly understand good code. In a big team you will spend a lot (most if you’re senior) of time reading other people’s code. Best to get good at it.

I have yet to be presented with a steaming mess of code to read and explain to an interviewer; yet it is the very first thing most new joiners face at any seniority level.