When I started down this path I just picked applications that I used a lot. For example I read the source code to `less`, and the manual. Despite "knowing" le

When I started down this path I just picked applications that I used a lot. For example I read the source code to `less`, and the manual. Despite "knowing" less I learned a lot from reading the manpage and reading the code. Same with GNU Make. I could say I knew it before I started, in the sense that I'd written simple Makefiles and knew how to run `make -n` , `make -j4`, etc. But reading the manual from start to finish, and reading the code meant that my knowledge was more complete. Some programs have terrible source code (e.g. "telnet"), and others good (e.g. "redis"). I think that a list of examples might be useful, but more useful still would be for people to choose things they know, and they use. Reading all about the design of postgres might be wonderful, but if you're not actively using it then the details aren't going to be so memorable. Better yet, because I read the source to programs I used I was even able to contribute bugfixes to them. (In the case of less/make at least. Not always.)