Ask Questions Based on Experience
My most powerful tool is to ask questions based on experience. When the junior programmer comes in with a design and you see a problem with how it will work in reality - ask the question "how will this work, given X element of reality?" Don't say - "this won't work because of X element of reality".
Often that has ended the discussion without conflict as the junior engineer goes back to the drawing board.
Be open to the answer
Once you've asked the question, be open to hearing an answer. Junior developers have actually taught me plenty about new technologies I didn't know enough about. I don't take their word for it - I do my own research, too - but sometimes they see things that I don't. Be open to the answer to your real world problem - they may just surprise you.
Pull in the big picture of the project
One of my biggest battles is usually developers who want to do their own pattern for design that it outside of the pattern being used in the rest of the codebase. It may, actually, be just fine in terms of that isolated area, but it is glaringly different when compared to the rest of the codebase, and my experience tells me it'll be a maintenance nightmare.
At this point, I push the developer to see the big picture with a few more questions:
- Are you saying all the code should be refactored this way?
- If yes, then how much would that cost? Will we still meet schedule?
- If no, then why is this area so strikingly unique that it should work different from the typical solution?
- What's the benefits of this vs. the existing way of implementing things?
- What will be the impact when someone who isn't you has to maintain that?
That's not to say that every new idea for implementation is bad... but there IS a value to no changing a known quantity and developers need to think about it before changing models midstream.
What's the worst that can happen?
There is no teacher like experience. If the junior engineer is developing something central and critical to problem, no way will I let a radical design fly without a ton of team scrutiny. But if the engineer working in a prototype, a tool or some other side area, it may be a good opportunity to try something that sounds wacky, but may just work - after all, you have to try new stuff sometimes...