I basically came here to suggest the same thing. The biggest part is a mental shift: realize that if you find a bug (or feature you'd like to have) in an open

I basically came here to suggest the same thing. The biggest part is a mental shift: realize that if you find a bug (or feature you'd like to have) in an open source project that you have the ability to fix it. The rabbit hole of reading code you go down of reading code when you do that is, I believe, the best real introduction to systems programming. Once you've been doing that for a while, you internalize the idioms. I'd recommend large projects because you're less likely to just end up copying some person or couple of people's quirks, and learning to read large codebases is a major skill in itself. The process of submitting patches often turns into ad hoc mentoring, where you'll be told what you didn't get right this go around. After you've done that for a while, you realize the same things apply to other large systems projects, and you end up exposed to a number of different styles of systems stuff.