I'll contest their is such a thing as good code. I don't think experienced devs always do the best job at passing on what works and what doesn't though. Universities certainly could do more software engineering/architecture.

My personal take is that SRP (the single responsibility principle) is the #1 thing to keep in mind. In my experience DRY (do not repeat yourself) often takes precedence over SRP -- IMO because DRY is easy to (mis-)understand -- and that ends up making some major messes when good/reasonable code is rewritten into some ultra-compact (typically) inheritance or template-based mess that's "fewer lines of code, so better."

I've never regretted using composition (and thus having a few extra lines and a little bit more boilerplate) over inheritance. I've similarly never regretted breaking down a function into smaller functions (even if it introduces more lines of code). I've also never regretted generalizing code that's actually general (e.g., a sum N elements function is always a sum N elements function).

The most important thing with all of these best practices though is "apply it if it makes sense." If you're writing some code and you've got a good reason to have a function that does multiple things ... just write the function, don't bend over backwards doing something really weird to "technically" abide by the best practice.