I think you are coming at the problem from the wrong viewpoint - the code is not the most important aspect of all this. The product is. You can have the most elegant, beautifully designed, most carefully crafted code that produces a useless, slow, buggy, un-usable product that is so badly documented no-one can understand or use it.
In fact, I'd say the "best" code always results in bad products because the developer is not focussed on making something that is simple and easy to maintain, that works according to the compromises required to make something practical. If you're too worried about all the little buzzword bits that are going around nowadays, you spend all your time trying not to repeat yourself or keep things separate that you forget the reason you're doing these.
Now this doesn't mean you should just hack whatever awful code together, but it does mean you need to focus the pride on the results. Results also include measures like communication and maintainability of code, not just working product BTW. For example, if there's no documentation that goes with it, and no-one can figure out how to use your beautifully complex OO API, then its no use to anyone.
So, how to encourage your young coders that pride in their work is a good thing. You can implement a system of feedback - if someone uses some code that they found easy to use or helpful, they can acknowledge the creator of that with a quick flag (similar to how sometimes a customer will send feedback concerning particularly good service). Then you can do code reviews - not the usual ones where the peers are involved, but where you pick a bug at random and go ask the developer to explain to you all about it, what they did, why they chose that approach, what supporting features they provided. Chances are you'll get the bare minimum and you can highlight what you expect, those that achieve your expectations can get a reward.