I've also begun to stress this in code reviews and mentoring interaction but the question is; how to present this idea in a way that "early in their career" dev

I've also begun to stress this in code reviews and mentoring interaction but the question is; how to present this idea in a way that "early in their career" developers (and not so early) can appreciate? Simply admonishing them about "keep it readable!" isn't effective in my experience. An example that frequently occurrs is decomposing a large method into smaller methods. Okay, there are now more lines of code (due to adding method declarations), but what was really gained? The gain that can be had is identifying common use cases and factoring some of those methods out to utility classes that can be referenced from the same source file and others. This can be difficult to identify unless one learns to really look for these oppurtunities. The approach I've been taking recently is presenting the idea as there's always a minimal level of abstraction, and code should try to achieve it. I'm interested to hear what others think about this.