My mentor was incredibly keen on knowing why you do something. I've seen many new developers come in, and they were taught that X is the best way to do something in college or from a blog or what have you, but they've never really understood why. So, when you introduce some new condition (let's say compliance), and you can't do X (or X is now remarkably costly), then what do you do? The best way to do this is to do code reviews, and have him walk you through it. Take that time to suggest better approaches, understand his thought process, and evaluate whether or not he understands what he did.
Code reviews take time, but it's the best way for you and him to get on the same page and understand each other. Don't approach it from a, "I'm an expert, and I'm going to show you up" context. Approach it as a learning exercise where he can learn from your experience, and you can learn more about how he works.
Another thing my mentor did was took me with him to meetings where we reviewed the code. Getting to know your users and understand who you're doing this for is incredibly important. So many organizations try to abstract them away. It was something that put a face to the end user, and gave the user confidence in us to understand what they needed. I've seen a lot of folks not have that opportunity, and want to build ivory tower software without ever talking to a user. It also makes the job much more rewarding.
Anyway, those are just a couple of ideas. YMMV. Best of luck--though, if you're asking questions like this, I'm sure you'll be just fine.