Lots of good responses here. One thing I'd like to point out:
In my prior job I joined early enough that I was able to keep the codebase very readable. As the team grew, I started running "office hours" to help allow newcomers to onboard. We were a globally distributed team, so it was hard to have the casual interruptions that happen when most of the team is in the same place at the same time.
In my current job I inherited a very crufty codebase, and I've spent a lot of time improving readability. Working with .editorconfig helped; and that initiative took ~1 month!
There are a lot of habits that can be learned by reading code; but mostly the reading is to look at style instead of function or "ideas."
One example of a good habit: My prior role involved a file synchronization product. We followed a naming convention whenever an object represented a file or directory. Merely naming a variable "file" or "directory" would be very confusing, because it lost a lot of context: Is "file" the entry in the SQLite database? Is it the in-memory type that we used to communicate known state about the file? Is it an object that's used to get things about the file from the file system, like last time accessed?
But, and this is where code != literature: The file synchronization product wasn't an "idea." The program was a very detailed set of instructions on how to synchronize files. It handled all the corner cases, because the computer has no ability to make assumptions when it follows these instructions.