First, put your ego aside. Start by assuming that he's not wrong, and that you are the one that is wrong, for two reasons:

1. All other things being equal, he's right and you're not, simply from experience
2. It's how you show respect

So ask him to teach you why his way is better, with the honest expectation that you are wanting to learn something, because you know, he just might know more than you in this case. Don't make it sound like you're asking him for a justification.

"Bob, help me understand something, please. I'm looking at how you had those table set up using Method X. When I first saw this, I figured we should do it with Method Y. What am I not seeing that makes X better in this case?" Note how you're giving him the benefit of the doubt of his having considered Y and chosen X.

Maybe he'll say "Huh, I hadn't thought of Y," and you can now discuss the merits of X vs. Y.

More likely, he'll tell you, "Well, the Xeno schema can overload the column history...." LISTEN as he explains. Consider that you could be wrong. Don't just champ at the bit waiting to tell your side.

And you can now say "ah, ok, that makes sense. I was thinking mostly about the benefits of the Yoyodyne widget," if it makes sense. And if it doesn't, ask "And you've found that that overshadows the benefit of the Yoyodyne widget?"

And if you've done it right you can now have a respectful discussion of the issues at hand.

The keys are:

• You're not telling him he's wrong
• You're not presuming to tell him "Yeah, but you didn't think of THIS"
• You're not demanding justification of his choice.

It's all about the Golden Rule, treating the other with respect.

Why not ask him to talk through the design and offer ideas? I found that as long as I don't come across as a jerk when I'm talking about a design most people are open to new ideas.

So much better to be honest (and professional) when you find an issue or don't understand something and think it might be wrong than to avoid the subject.

The two wrong things to do are A) nothing and B) take an accusatory tone in your critique of the design.

The point is that you two are on the same side and you'd want him to do the same thing if you were heading down the wrong path.

It's all in the delivery - communication is key, always.

Just my two cents.

Best of luck!

Let it go.

If his solution works, then his solution should stand.

Keep your mind open, maybe you can learn something. When you are the mentor for a less experienced developer, it will be your turn to make the decisions.

EDIT:

If his solution doesn't work, or if it has a flaw (performance hit, etc..) then you have an in to suggest an alternative.

"So how do I go about telling him this?" You can't.

You can, however, find out why they chose their solution. Learning will have one of the following outcomes.

1. You learn something new, and revise your opinions. There may be reasons that you don't know about yet. They may not be good reasons, but at least you'll know what they are.

2. You find a specific deficiency that you and your mentor can explore in depth until your mentor realizes the problem and provides a new solution. At some point your mentor may provide you with the solution you have in mind. Success. Or, your mentor may improve on your solution. Success.

3. You find that the organization isn't appropriate for you.

Can you objectively list pros and cons of each approach (the one that's currently in vogue and the one you're proposing?). If so, you can casually ask ", I have a question for you.. Just been curious, you know..." and lay out what you think in front of him. If you do it in private and in good faith, I'm sure he'll probably reply something like 'Er.. yeah... now that we mention it... you know how rushed we were in the pervious iteration etc.. etc..'.

It's important that you ask in private and very politly in a open, willing-to-learn mode. The sr. programmer should not feel challenged here (especially, since it was not your area ;)).

You could offer to help him by putting in extra time / working in spare time to implement this yourself.

Make sure that this is not an insecure person who's not sure of himself... you may find yourself in a conflict situation...

Best of luck.

Simple.

Ask questions that directly/indirectly lead to weaknesses/pitfalls of this approach, and have this person realize that they are wrong.

Worst case, they properly explain how you are wrong or they ignore you completely. In the latter case, you don't have the best mentor if you can't discuss various alternatives with them. :)

I'm not saying you need to absolutely prove you are right, however. It is true that it is often wise to let it go.

Think from all angles. Be patient. Whatever improvements you are thinking of suggesting, dont make it look like a "pure" technical solution or something you just came up with. You can easily get branded as a Techie with a narrow view. Your suggestions should be based on overall objectives, requirements or reasons like performance, scalability..

You have a few choices:

A. Quit and start your own consulting company.

B. Tell him you want to better understand the over system and ask him to explain the history and reasoning for the design decision. Follow up with the question: Are you and the team open to considering another approach?

C. Put your head in the sand and keep your ideas to yourself while allowing a deep sense of resentment and frustration to build until you explode and quit.

Personally, I'd try something like B. If I was still terribly unhappy about the result, I'd probably turn to C. :)

It's a tough one but...

Telling anybody they are wrong is a bad idea. Find some things you can agree with this guy about and appreciate him for his strengths. Come back and revisit this when you know your colleague and the company better. I realize that this decision will probably be made by then, but you will be in a better position to influence future decisions by then.

"Telling" someone they are "wrong" is beside the point in your example.

Developers don't improve themselves, their projects, and each other by shooting incontrovertible facts around or by, merely, telling people they are wrong.

They discuss.

Open a dialog with the other developer. Express your point of view, back up your point of view with facts. Listen to his point of view. Question assumptions. Ask "why", a lot. Answer "why", a lot. Avoid personalizing the discussion. Avoid shouting. Avoid playing the "gotcha" game. Work toward a solution collaboratively, it may end up being better than any solution either you or he could have come up with independently.

Read Crucial Conversations ^[1], and apply the advice therein.

I would ask him to try to walk you through it. You can even say that you think there might be a better way, but acknowledge that it may be naive. I've been on both sides of the fence here, and it might actually work out, you just can't go in guns blazing. If you're wrong, it could be a great learning experience, and if you're right you might get a little respect.

Since you're saying that he's been good at mentoring, you could try phrasing your proposal as a question. Approach him as a mentor and ask him why he made the decision that he did -- he might list reasons that you're not aware of. Once you get into this conversation, you might ask how this approach would compare to your alternative -- I'm sure it has both pros and cons.

As long as you do this in private, and don't put him on the spot or outright say "your design sucks (and by implication, you do)", he will probably be happy with the discussion and respect you more for it. He might even adopt your approach if feasible. Depends on how much of an ego he has...

When starting the discussion, your goals should be to learn, not to argue or win. If his solution sticks, so be it.

Present your ideas in such a way that your mentor has a say as to which of them to implement. This way you get what you want while leaving the decisions to your mentor.

If this is a large project your new ideas may take into account the broad picture of the entire system and could cause unintended 'features'.

When I started out as as coder, I too had a mentor for a number of months (and interestingly it was 4thGL too (Progress in my case)).

As other's have said, this really is not a case of right and wrong, but by month 2 I did feel I could query certain decisions he made. I think the only real mistake you could make is to not "confront" him with your own ideas. Maybe he overlooked something in which case he'll admire your perspicacity, or else you may learn a trick which isn't taught in a reference book.

Either way, he should take it well. Hopefully he remembers what it is to be the pupil.

Lay out an alternative that you think is appropriate (rather than frame it as a problem, lead with a solution). Be polite and give concrete reasons for why your alternative is appropriate. Present your position and listen to his. If you can't convince him with sound technical reasoning, let it go. Don't make it hostile or political and you should be fine. Consider writing out your position so that you have a very clear idea of the problem and your solution.

"Would it be easier* if we did it this way?"

*faster/more maintainable/less prone to bugs/etc.