Personally, I like to go back in the git history to when things were simpler and see the changes to the codebase that solved specific problems they had, e.g; scaling, reusability...
I often find the best service someone experienced can render to someone unexperienced is the service of curation, i.e. hand pick from the vast amount of available options a few that are likely to help.
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.)
Ideally, you’d find a mentor who can review your code and give you pointers on how to improve it, with explanations on why those things would help. Those mentors aren’t easy to find either, but still...