Nuance is needed. Multiple sources form the overall picture. I found that doing hard things in an embedded or conventional shipped product team is the best way

Nuance is needed. Multiple sources form the overall picture. I found that doing hard things in an embedded or conventional shipped product team is the best way to learn, and that working with effective people who used a particular language reasonably defensively and obviously for maintainability contributed the most code value. For example, I taught myself Pascal, C, C++, assembly and Java (badly) before attending undergrad. The good thing about the ugrad program I had was that there were SGI, HP-UX, Solaris and Linux boxes such that writing portable C was essential.. you couldn't turn in a project if make didn't work on every platform because they wouldn't say which one they would use ahead-of-time. Then, I had an embedded internship at GPS manufacturer to work on 900 Mhz and 2.4 GHz radio firmware where a C++ subset was used on a codebase that spanned about 100 products. Also, lots of refactoring test/flashing tools was required because of commented-out code remnants were checked-in and 2000-line megafunctions because interns just banged-out code without any enforced coding standards.