Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I am a new programmer at my office. I just entered this workplace for about 2 months.

I've been working with another senior programmer which is essentially my "mentor" during the introductory period. I've been studying a lot for the past 2 months and I believe I have a good grasp of the system already. And I feel that one of the design decision that this senior programmer made is not very good and I have a better solution.

So how do I go about telling him this?

I'm not a junior programmer by any means I've been programming for some time. But they are using a custom 4thGL. So I can't say that "I have 5 years experience in .net and this is bad in my experience" or something like that. And we are working on different parts of the system and his part doesn't actually falls under my "jurisdiction" really... But I will eventually end up diving some parts of it sooner or later, and it is a major part of the system and I feel that a lot can be improved by doing things my way.

But I don't want to be the snobbish little kid that just joined the company, and I do want an ongoing good relationship with my colleague especially since he helped me so much during the first week or 2 when i was there. But i feel strongly about this.

So what is your opinion?

share|improve this question

migrated from stackoverflow.com May 21 '11 at 10:39

This question came from our site for professional and enthusiast programmers.

can you give a little more specifics - eg I believe this is wrong because –  KiwiBastard Oct 17 '08 at 1:17
OK, but have you considered that if you can't explain the problem succently in a few lines, then perhaps you don't know the problem as well as the other guy? I've had Juniors who thought they knew the solution but when we talked it thru didn't think of all the edge cases.. –  KiwiBastard Oct 17 '08 at 1:33
2 months is too little to understand the context / requirements fully. It seems to me he has just presented his solution instead of really explaining the "why?" –  rshimoda Oct 17 '08 at 7:41
@Ben I kept my mouth shut on that one. Later found out that he's not wrong, but I wasn't wrong either. It's just one of the quirks of the software. Our software have many of these quirks. So basically in other similar situation with him I've used Andy's approach. –  paan Sep 9 '09 at 3:24
Is it important enough to change? The solution may be good enough as is! –  user1249 Jul 14 '12 at 18:25

18 Answers 18

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.

share|improve this answer
Yup, communication and respect are key. And sometimes really difficult. –  tsellon Oct 17 '08 at 1:50
This is good advice BUT it won't work if he's made a bad decision he can't back out of. –  Draemon Oct 17 '08 at 2:19
You have to consider non-code reasons too such as budget for the project / expected performance before you give out your opinion –  rshimoda Oct 17 '08 at 7:43
Great answer, and I want to add: bear in mind that he may stick to his approach during your conversation but then keep thinking about it and change his mind later. That's happened to me many times. –  jhocking May 21 '11 at 11:05
@Draemon: Even if the choice was a political one, not a technical one, he is probably still right in the greater scheme of things. And if he can't back out, he might just tell you so - "Oh, I hadn't thought of Y, too bad we've already done X", and he might even explain the reasons. –  tdammers Feb 24 '12 at 11:56

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.


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

share|improve this answer
I disagree. In many teams, this would be shirking responsibilities. All team members should give voice to their concerns and ideas, for the benefit of the team. See my answer below for how to do this respectfully. –  Andy Lester Oct 17 '08 at 1:33
Sometimes it's just better if the padawan just sits there and learns. –  mattruma Oct 17 '08 at 1:41
-1 If the padawan sits & listens but never asks questions, how much real learning can there be? –  MarkJ Jul 14 '12 at 19:07

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!

share|improve this answer

"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.

share|improve this answer


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.

share|improve this answer
@Mark: concern about who gets the credit shows that you're the one with the ego. –  Paul Tomblin Oct 17 '08 at 1:27
Agree with Paul, you're working at the same company if you keep your ideas secret merely to avoid having credit for the idea poached you either have too big of an ego, are too paranoid, or need to find someplace else to work. –  Wedge Oct 17 '08 at 1:34

"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, and apply the advice therein.

share|improve this answer

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.

share|improve this answer

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. :)

share|improve this answer

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..

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

As a senior developer (in job description anyway...) I can say I don't have a problem with this, as long as the objections are reasonable.

Most likely I'd either say "Actually, it works this way because...." or say "Yes, you're absolutely right. It seemed like a good design at the time, but turned out not to be ideal." Most likely then adding something about how I wish I could change it but the advantages don't justify the cost of doing so...

share|improve this answer

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.

share|improve this answer

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'.

share|improve this answer

This depends on the company's culture, and how smart are your colleagues. Assuming that your senior developer is really wrong in that aspect, a smart senior developer will keep an open mind and accept your solution. Not just that, but will think that you are very smart. Smart developers will admit their faults.

In close minded firms where you are working with average Joe developers, face is most important and you probably should not mention that his design is wrong because it might have an negative effect on your relationship.

If you are asking this question and hesitating, it probably means that you are working in a close minded firm with average developers. In this case, I would keep my trap shut.

share|improve this answer

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

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

share|improve this answer
What are the "*" for? –  Dynamic Jun 1 '12 at 20:15

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.