Recently, I started my first job as a junior developer and I have a more senior developer in charge of mentoring me in this small company. However, there are several times when he would give me advice on things that I just couldn't agree with (it goes against what I learned in several good books on the topic written by the experts, questions I asked on some Q&A sites also agree with me) and given our busy schedule, we probably have no time for long debates.

So far, I have been trying to avoid the issue by listening to him, raising a counterpoint based on what I've learned as current good practices. He raises his original point again (most of the time he will say best practice, more maintainable but just didn't go further), I take a note (since he didn't raise a new point to counter my counterpoint), think about it and research at home, but don't make any changes (I'm still not convinced). But recently, he approached me yet again, saw my code and asked me why haven't I changed it to his suggestion. This is the 3rd time in 2--3 weeks.

As a junior developer, I know that I should respect him, but at the same time I just can't agree with some of his advice. Yet I'm being pressured to make changes that I think will make the project worse. Of course as an inexperienced developer, I could be wrong and his way might be better, it may be 1 of those exception cases.

My question is: what can I do to better judge if a senior developer's advice is good, bad or maybe it's good, but outdated in today context? And if it is bad/outdated, what tactics can I use to not implement it his way despite his 'pressures' while maintaining the fact that I respect him as a senior?

  • 26
    You learn more from mistakes than successes. – StuperUser May 23 '11 at 17:54
  • 45
    Can you give an example of one of the issues you two disagree about? I know this is more of a theoretical question, and you probably want to avoid technical debates, but it would be interesting to hear what the disagreement is over. – Adam Rackis May 23 '11 at 18:09
  • 140
    I see one red flag in this post. You have had to be asked to do something three times. Once should be enough. If you don't want to do something, you need to convince your mentor it isn't necessary. If you can't do that, then either hold your nose and do it, or find a new job. – PeterAllenWebb May 23 '11 at 21:50
  • 6
    @peterallenweb, indeed it is bad to be asked 3 times regardless of the quality of the advice. I guess from the comments here I have a lot to learn in terms of working in different teams. :) – learnjourney May 24 '11 at 0:10
  • 33
    In addition to what Peter said: Consider his point of view: You ask the new guy to do something, have a technical discussion, get no further objection, and then - a week later you find out he simply ignored your request. And this isn't the first time this has happened. (Don't worry too much - you're certainly not the first person straight from college to fall into this trap. As long as you are aware of this issues and work on them, you'll be alright.) – Martin May 24 '11 at 8:48

33 Answers 33


First, as a senior developer, I expect the juniors I lead on projects to bring their concerns to me in a straight forward and direct manner. If they disagree, that's perfectly alright with me. In some cases, I will take action on their concerns. In most cases, their concerns are tossed aside put aside with a short explanation of the reasoning, not out of disrespect for the developer him/herself but because of some other reason such as:

  1. The junior doesn't have all of the information at hand to understand the decision as it's been made. In some cases, a little explanation can help the developer move on past the concern and deal with an unideal situation.
  2. The junior has BAD information. Don't forget that you are, in fact, a junior. That's the equivalent of being a teenager in software terms. I'm sure you have a lot of great ideas, but it's just possible that you don't know everything. I find the most resistant junior developers are the ones who firmly believe they know what's best for the code, the company, the world. These developers are better served by acquiring humility.
  3. The decision to do something a particular way was made above the senior's head. The senior still works for someone else in the end. There may actually be a better way to do something, a more efficient way to write something, or better software/hardware to help do the job. The business still drives the decisions though. Business managers, directors, VPs, etc. often make decisions that impact the development process. These are beyond the control of the senior, and when the juniors complain about it, all they're doing is adding to the senior's stress.
  4. The senior just flat out doesn't have time to take it into account. There are deadlines, and sometimes changing patterns, practices, and behaviors midstream is costly to that deadline. Since it's his neck on the chopping block it's often more important to get the product out functional and on time than "perfectly written".

These are just the things I can think of off the top of my head. There are a ton of reasons why an idea, practice, concept might be dismissed or discarded by someone higher up than you. Many of them are unpleasant, but they all boil down to the fact that we're all human and we all have opinions. His opinion just happens to be numerically superior to yours at the moment.

Bearing those concepts in mind you should continue to bring your concerns to the senior developer. Find another senior developer who may be able to fill in the blanks. Many senior developers are where they're at because they are better with software than with people. Some are where they're at because they knew whose butt to kiss when they were interns. Find one who actually understands what it means to mentor someone and get their honest opinion. They may disagree with you and fill in the blanks you don't have. They may agree with you and help to rally your cause or make your situation better.

At no time should you mount any kind of insurrection. Even if you believe in your heart that your way is right, you have been given an instruction to follow and you should follow it (unless it's illegal obviously). If you have trouble following these instructions, you may want to try to reason out why because you're going to discover this pattern of behavior to be very prevalent in very many companies that produce any kind of software.

Your best option is to continue to do your job ethically and professionally. Get the software you're asked to do complete in an exemplary fashion and escape the situation by being promoted out of it. If promotions don't come, you'll have plenty of references and experience to pursue opportunities in other departments or companies.

  • 47
    @Joel Good answer, but beware of "tossing aside" concerns. Concerns should always be acknowledged even if they are invalid, even if the best response you have is "I understand your concern, but right now we have to do X because of Y". Perfunctory dismissal of earnest ideas is a morale killer and can eventually destroy even the most healthy of cultures. – Rein Henrichs May 23 '11 at 18:24
  • 42
    @Joel: A lot of good points, but this is a bit condescending: "That's the equivalent of being a teenager in software terms." The respect that a senior earns from the junior developers is won by consistently making good decisions — not by the mere fact of age or seniority. – Neil G May 23 '11 at 21:05
  • 26
    It doesn't come close to answering how you know if a senior developer is "good" or not. The answer as stated here appears to be "it doesn't matter just do what he says." I'm not saying that's wrong advice; I'm just saying it doesn't answer the question. For what it's worth I think the only right answer is you'll know if he's any good in 5 years when you're a senior. – Kevin May 23 '11 at 21:16
  • 2
    @Kevin: I can't argue with that comment, and I certainly can't recommend to a junior developer any method to determine a way to answer that specific question. Often seniors can't answer it accurately about each other. My answer was honestly geared towards some of the other aspects of the OPs question that struck me as more pertinent than how to spot a crappy senior developer. – Joel Etherton May 23 '11 at 23:18
  • 11
    It looks like the answer lacks that humility you speak of. Young people often think they know everything, but don't senior people share the same vice? This is exaggerated in our industry - a big part of the knowledge we have will be less relevant in a few years. (real life example - I've have a mentor in a medium project who said we should "make some buttons and write SQL in them, to save time". He was quite impressed when I showed him LINQ to Entity, and asp.net page with no code) – Kobi May 24 '11 at 4:36

Respect the senior developer. He is more on the line for the success of the project than you are. Since he has the responsibility he also gets the authority. If he says change something then do it.

That being said, don't hesitate to present your concerns, when you encounter a problem like you already have.

Lastly, sit down with him and explain to him the same question you posted here. Maybe you are missing something big, maybe he will open up more to your suggestions, either way, don't keep him in the dark if you think his advice is poor.

  • 29
    OP - you're both professionals, even if you have less experience, so have a professional discussion with him about the things you question. If he isn't willing to talk about the whys of his instructions, he isn't much of a mentor. – DaveE May 23 '11 at 17:09
  • 10
    +1 For "He is more on the for the success of the project than you are". How true it is. I know you junior developers don't appreciate how lucky you are to not have that kind of stress on you because I sure didn't when I was a junior developer. Now get off my lawn! – maple_shaft May 23 '11 at 17:23
  • 1
    I'd also suggest that if/when you do follow his suggestions, keep a document of your concerns regarding the change -- if it breaks later on, you may be able to point to this to show that you predicted the error. – Daenyth May 23 '11 at 18:11
  • 4
    @DaveE: Sounds like they have already had the discussion and the OP just did not have enough context to currently understand the wisdom of the senior. Sometimes there is only so much you can explain the rest will need to come from experience. – Martin York May 23 '11 at 18:20
  • 2
    @Niphra: Possible. But without more exact information I am more inclined to believe that this is just a naive learner that knows less than he thinks. Most seniors actually know what they are doing (you don't become a senior engineer if you are stupid you go into management instead). – Martin York May 24 '11 at 18:35

When this happens, what you need to do is have a conversation with the senior developer. Perhaps he knows something that you don't about the code or the technical/business requirements. If so, you should learn it.

Do so in private. It might be seen as challenging authority, and such things are best done one-on-one. Show a willingness to compromise and collaborate by acknowledging and respecting his seniority, but be persistent in getting your questions answered. Approach the situation from a collaborative frame, not a combative one. You might consider asking him to mentor you.

At the end of the day, you have to balance your own ideas (which, to be fair, are relatively new and untested) with his. Perhaps you are indeed right, but you should do your best to learn from more experienced people so you can make a more informed decision. A good senior developer welcomes the opportunity to collaborate, mentor and learn, even with junior developers, and welcomes having their ideas challenged in a constructive way because they too know that they are sometimes wrong.

  • 4
    +1 for having a conversation. The senior developer may be better able (and responsible) to balance different concerns, but he should be able to explain his reasons. Explaining yourself to juniors, so they can learn, is a big part of being a senior. And if you as a junior don't feel like you're learning, maybe it's time to change jobs. – Jaap May 23 '11 at 18:16
  • +1 for best done one-on-one. The time for disagreement is behind closed doors. When the door opens and the discussion is over there should be no squabbling, no underminding, no whining. Don't open the door until you get to that point. If you still disagree, tell the senior to his/her face that you intend to elevate this to his/her supervisor. – Michael Riley - AKA Gunny May 24 '11 at 12:51

The way you often tell is through a common sense approach. Keep in mind that the senior developer may know more about the project, but might not know more about the right way to do things. You have to gauge what he tells you to do - he's giving you bad advice if what he says flies in the face of what his betters claim (i.e. people more senior than him; not necessarily in your company... I'm talking about well-known "celebrity" developers who often post or write books about the correct way to do software development, or at the very least industry-accepted best practices).

Here's an example of "bad advice" from a senior developer (or any developer): If they are totally ignorant of what loose coupling is and why it's a good thing, and you are told to write all code in, let's say, the code-behind of an ASPX file, it's obvious the senior developer is clueless and his advice should not be listened to.

If, on the other hand, he is telling you how a specific module in the system works, it's often best to listen as long as again, what he's telling you doesn't spit in the face of proper development principles.

Here's my rule of thumb: A senior developer at a company might simply be the developer with the longest tenure; he might not have any real skill. Is he saying things that go against what some of the most respected developers in your field say (people with much more experience than him, and who are a lot more competent and respected)? If he is, chances are his advice is bad unless there are very extreme circumstances.

Fully expecting downvotes/disagreements for extremely biased viewpoint.

  • I have to admit I am actually shocked that I have seven upvotes (as of now) and no downvotes. I would have thought my attitude/pessimist view/ranty tone wouldn't have sat well with people :) – Wayne Molina May 23 '11 at 20:31
  • On Slashdot, announcing that you expected to be modded down was a tried and trued technique in karma-whoring. – Carson63000 May 23 '11 at 20:54
  • I'll have to try that more often j/k :) – Wayne Molina May 23 '11 at 21:31

It may be hard to understand the vantage point of the senior developer, and yes he may be leading things down the wrong path, however when it comes to large projects, consistency is more important.

Having 50 some developers all following their own coding styles, standards, methodologies, and design patterns would be utter chaos. If things are being done wrong it is always better to be consistently wrong than many different types of wrong and some things that were done right.

When it comes time to perform maintenance, add features, or fix what is "wrong" then it is much easier if the problems with the existing design are known upfront.

It is good to respectfully disagree but in the end you are best to fall in line. Anybody on a team who goes rogue is not seen as a team player.


If the senior can't give you good reasons why they are ignoring industry best practice, then don't waste your time there. You will never advance because you are too threatening, and anyway, do you want to spend time maintaining a pile of bad code?

Most developers stop reading when they leave college. You haven't, so you are already in the top 10%. There is plenty of opportunity these days. If there's no job market in your town, then look for a better town.

  • 9
    Blindly just saying "we need to do industry best practice" may not be the best way to open a discussion. There might be very good reason for doing something else than most others do. – user1249 May 23 '11 at 21:12
  • 7
    I think this is the closest yet to an actual answer. A senior developer should be able to provide convincing reasons that the methods they advocate are reasonable. You won't be able to improve under the mentor-ship of someone who can't. Now, if you find yourself on your third company and all the senior devs at all of them were idiots in your opinion, it may be time to take harder look in the mirror. – PeterAllenWebb May 23 '11 at 21:47
  • 2
    @PeterAllenWebb, "should be able", yes, but you do not necessarily want to argue hour after hour pinning out in detail why you have found a given practice to be bad for you. Occasionally, "why?"'s can be answered with "Because!" – user1249 May 24 '11 at 5:49
  • @Thorbjørn Ravn Andersen: I agree, as long as it is occasional. – PeterAllenWebb May 24 '11 at 15:21

Wow that's a wonderful opportunity for you to shine and show off your skills. Early in my career, I had someone who was my supervisor who was unable to make a decision, any decision, so I used that opportunity to learn how to do the work of the next higher level up. It got me promoted. You should do the same.

  • I appreciate your thinking, but i am afraid of the future and speculative as there can be more tough situations, in which posting to forums might not help. What should i do then? – developer123 Aug 19 '11 at 13:21
  • 4
    Dig into the books and learn in depth. The Internet is not the only way to learn. Join a local developer group and make contacts with more senior people that you can get to mentor. – HLGEM Aug 19 '11 at 13:33
  • that's a good one. – developer123 Aug 19 '11 at 13:42

As a senior developer this type of passive aggressive nit picking would drive me crazy and after confronting you would drive me to give you a bad review. The perfect solution is the one the team can live with together.

As for style this should be dictated by your style guide and best practices determined by your origination. If you are passionate argue for it, but once a decision is made live with it and work with in the bounds of the team you are on.

  • 6
    As a junior developer this type of dictatorship would drive me crazy. I down-voted, sorry. – kizzx2 May 24 '11 at 16:43

You're in a not-so-good situation but, as HLGEM pointed out, you can turn these positions into blessings-in-disguise. Your question is multi-faceted, so I'll approach it in parts.

I suspect, he does not know. At the same time, he tries to show me arrogance may be so that i don't turn up to him much for questions.

This could very well be true. There are a rash of developers who have been in the industry for decades and not be capable software leads - from a development or a mentoring standpoint (there is a difference). Experience comes from tackling fresh challenges and trying new ideas and learning new skills, but the majority of programmers spend their lives in a wing of The Corporate Office, working on The Payroll Application with their faithful Visual Basic and Java tools, never seeing the world racing by their cold, grey office.

There's nothing wrong with this. For many developers this all they ever wanted and are perfectly content with the situation - it is not, however, an ideal situation for fostering a future generation of programmers, let alone lead developers.

Bravado and arrogance can be a defense mechanism, trying to cover for inadequacies. How do you handle it? Don't confront it head on - if your lead is incompetent, and the boss is unwilling to rectify the situation then you'll have to live with it. That doesn't mean roll over and die, but you can't force somebody to be a good lead.

However, he just only reviews my code, and most of his comments are related to coding guidelines

This is what makes me think you're right in that he may not be a good programmer. That's not to say that he isn't a better programmer than you at the moment (at the very least he'll have more experience and exposure from being in the industry for so long) but again, that doesn't translate into being an effective lead. Guidelines are all well and good, but they are second to the function, effectiveness, and efficiency of the code.

What should i do in such situation?

I have informed my manager of this situation, and i have requested him to change my lead, although he tells "yes" everytime, but he does not take any serious action.

Have you enumerated all of these specific points to the manager, and with specific examples to back it up? If you've simply gone to him and said, "I need a new lead", he won't take you seriously and perceive it as an "interpersonal problem" rather than a technical problem. The reaction of a lot of bosses in this situation is to ignore it in the hopes that it will "work itself out".

Here's some suggestions.

  1. Don't chafe at your situation - trial by fire, while not fun, teaches you some critical researching skills for later in your career.
  2. Start pushing your lead to be more involved. Do this carefully and respectfully. Continue to push and be persistent until he gives in (this actually works for a lot of situations in life).
  3. If your lead won't get involved, see if there are others who could help you. Unless you're working in a sweat-shop that is only concerned with milking hours then your company won't mind another developer with more experience showing you some ropes and reviewing your code.
  4. Start keeping an eye out for a new job. I wouldn't say that you're in a "must leave" situation but it wouldn't hurt your career to be in a place that takes your development as a programmer more seriously.
  • Thanks a lot, your points are really nice and thoughtful. Upvote for you. – developer123 Aug 19 '11 at 14:28
  • Thanks, i have selected your answer, as it combines the best. – developer123 Aug 20 '11 at 6:00

If you have a better way to do solve a particular problem, just DO IT.

Let your code/solution be your best argument. Otherwise stick to what you have been told.

Case in point

when I was a junior I had a situation where a particular section of code was not the best it could be. Rather than just debate about it, I simply improved it THEN showed the results to my senior. He accepted it, because the code is always king.

  • 11
    @maple_shaft: what kind of a team are you if code (and everyone maintaining it) has to suffer to protect the senior devs feelings? – Jaap May 23 '11 at 18:02
  • 1
    @Jaap, First of all I am talking about a tech lead or project lead, this need not necessarily be a senior dev. Secondly, it is not about their feelings, it is about moving towards a common goal as a group. The lead should have some semblance of control over his group regardless if he is wrong. The lead is the one who takes responsibility for buggy code that is put out, incomplete features, and missed deadlines so if he is a fool then he will suffer. If the company doesn't recognize he is a fool then the company will suffer. – maple_shaft May 23 '11 at 18:12
  • 2
    If he has already been told to change it then it has failed code review. Just trying to re-submit it means he will get told this has already failed. – Martin York May 23 '11 at 18:22
  • 2
    @darknight, assuming this is not some tiny issue, changing paradigms on an existing codebase could have some serious reprecussions. What comes to mind when I think about these sorts of debates is database structure. Changes like that will most certainly not be appreciated. – Morgan Herlocker May 23 '11 at 18:22
  • 1
    This only applies for very small units of work. Say you worked for two weeks, and the code is rejected - how will you get funding for those two weeks? – user1249 May 23 '11 at 21:10

Of course as an inexperienced developer, I could be wrong and his way might be better so my question is what ways can I do to better judge if a senior developer advice is a good or bad/outdated one.

You can become an experienced developer. Until you do that, you'll be ill-equipped to judge whether or not your intuition as a junior was right, and by then it won't matter.

In the mean time, read Joel Etherton's answer.


I would strongly suggest not trying to "not implement it his way".

So far, it sound like you have done the right thing. You were humble and brought up a counterpoint. I could not tell from your question whether you simply disagreed with his method, or you disagreed and presented an alternative. Bottom line though, always offer a clear and thought out alternative when you try to shoot down someone else's approach. As he might see it, you have a good idea that might work, and he has an idea that does work.

In any position, we are forced to do sub-optimal things all the time. If you really don't like it, then you can do as you did and bring it up. After that, its the boss' way or the highway. On the brighter side, you are insulated from much of the risk of poor decisions as a junior.


Pick you battles. If your talking about an hour of work your going to have to change your code at times until you work your way up. Next time you get a large project ask ahead of time for a chance to present your ideas before starting. Put in some extra time and make a amazing demo or prototype.


Shockingly enough what I've done is to just stop asking. When given another option I just digress and do it his way but add my own flair to it. Use it as a learning experience to build your abilities and still pacify his or her need to keep it old school.

In the end not every senior developer pays attention to new ways of doing things. They at times have old school ways that were great for the language they started on 20 years ago but are considered to be hacky, or "have a bad smell" in todays world.

This may sound like an awful way to keep going, and it is. But I've also learned a lot from my seniors way of doing things. But this is really just my opinion. In the end you have to be happy at your job and keep distractions and tension at a low level. And by not objecting to things you will see stress go way down.


Don't trust senior people because of there seniority. Challenge authority as often as possible. A competent authority should be able to convincingly answer any question. That's what makes him an authority in the first place, isn't it?

Because someone holds superstitious beliefs for all of his life doesn't mean he is right. Remember, in the middle ages people believed that the earth is flat and some of those self-righteous asses even felt justified killing the doubters. It turned out that the doubters were right. So much for bad reviews.

Never fear a bad review. Would you trust a blind man judging color?

  • 5
    Most managers won't have much patience for a junior dev who challenges everything. If yours does, go sacrifice a chicken in honor of Cthulhu, 'cause you've found a great boss! Otherwise, be prepared to shop around a lot until you find one. – user25946 May 24 '11 at 13:10

good answers above, would add that a response like "best practices" or "more maintainable" is an opportunity to learn something. You say, "Can you give me an example of why that way is best so I can understand the difference?" or "In what situations would this way be more maintainable that some other way, so I can learn to plan ahead like that?"

If the senior is right, giving you an example will be easy. If he is a parrot... give him a cracker to stop the squawkin', and do what you think is best. Until ordered to otherwise.

If the senior's role is to mentor, he will explain why when asked.


As HLGEM and Jarrod said before this is really a blessing in disguise. Both of their answers are great and I want to add some points.

As your lead is not in your domain you get to take some of the important decisions for your part of the application as your lead doesn't know much about middleware. You also have closure with your manager about how the application should go, what the product users want and how your manager would want to tackle a situation presented to him by the product team. Tell me how many people will get that kind of knowledge on an application.

When you are in a large team you will sure have help from your teammates and/or your lead but you will not have the knowledge of how your manager thinks or the product team thinks because that kind of thing generally goes through your lead and may be some senior devs in a team. I agree one person projects are kinda tough to carry but if the other side of the coin is so great why miss a chance. Learn what you can learn, enjoy while you can and if it gets too hard convince your manager as Jarrod said or find a new job/project depending upon the situation.

  • Thanks to you, HLGEM and Jarrod for pointing out the positive parts. – developer123 Aug 19 '11 at 14:57

You're going to be dealing with people like that your entire career. And there will be many with whom you will disagree about the best approach to any coding problem. The best thing I think that has worked for me over the years is that if they keep pressing on an issue, be up front with them and tell them that you have considered their solution amongst the various possible solutions and that you felt that the solution you settled on was the one you felt was the best approach in this situation.

Now, if you choose against their advice every time, then occasionally you may need to give in and use their "advice" from time to time just to smooth a few ruffled feathers. As long as they don't feel you're rejecting their input every single time, then that will go a long way to keeping the peace between you.

Consider also that they are a senior developer and have been working in that environment for longer than you have. Real life coding often doesn't mesh with best practices or community accepted standards. There may be a reason that they recommended you do something a certain way that they are not able to articulate fully. So even if you disagree with them, make sure you don't dismiss their advice out of hand based solely on the fact that you believe your solution is better.

It's all about balance. And not just coding balance, but team balance. Many a project has failed not because the developers weren't capable of doing it, but because they couldn't find ways to work together amicably.


I would like to provide some stuff from my personal experience, which should be considered as a supplementary answer to one posted here by jzd...

  1. Ask another senior developer,
  2. Do research on your own.

In one professional appointment, I was supposed to be mentored by someone senior. He knew some stuff but honestly not that much, unfortunately he did not know it, so he was ultra confident on his answers. I somehow felt that what he said was wrong. I had some evidence when stuff he did were against the best practices mentioned in the MS certification I took :-). After that I started asking other people working in other companies (stackexchange was not up and running back then) and started reading blogs to compare answers.

It would be great if I was wrong, cause I'd just change my behaviour, but I wasn't.

  • 5
    There is almost never a valid reason for ignoring industry best practices except ignorance and/or an unwillingness to do it right. They are "best" practices for a reason, and the people who come up with them are ten times smarter and even more senior than the senior developer who ignores or is unaware of them. – Wayne Molina May 23 '11 at 17:26
  • @Wayne M: Well said. – Jim G. May 23 '11 at 17:51
  • 6
    @Wayne, you still need to understand why they are best practices. If you blindly say "this is best practice, we need to do it!" without knowing why, you are no better yourself. – user1249 May 23 '11 at 21:16
  • I'd say Wayne left enough room in his answer Andersen's rebuttal. – C Johnson May 23 '11 at 22:18
  • @Thorbjørn Ravn Andersen, @learnjourney - Of all the comments and answers, Thorbjørn's comment is probably the single most critical and relevant piece of advice. You must understand the problems a given best practice was trying to prevent or solve otherwise you will never know whether those problems still apply. In short, you must understand why it is a best practice. That is how you suggest alternatives: by illuminating the problems that the best practice solved. As the Merovingian from the Matrix said, "Without "Why" you have nothing." – Thomas May 25 '11 at 17:43

I've noticed something over the last few years, nearly every company I'm at, with nearly every project I work on, with nearly every new hire (regardless of skill/experience level) wants to do something 'different'.

It might be the coding standards or the overall architecture or the language or the methodology. But it's always something. A lot of times, it's just stating the obvious, 'Shouldn't everything be documented better, for our end users?'

My advice to you is don't be that guy.

Some day, you'll be a kick-butt senior level guy who is hired and paid to make those decisions. When that day comes, go to it! Until that day, realize what your position is. I have a boss, as far as I'm concerned my entire job is to make my boss happy. It's not to second guess decisions made outside of my pay-grade. If you really aren't sure, talk to your boss/supervisor and find out.

Generally speaking though, it's far better to have everyone on-board with an outdated approach than half the team following the outdated approach, 1/4th of the team following some new approach and 1/4th of the team trying to develop a cutting-edge, brand-new approach.

  • 17
    -1: I have a boss, as far as I'm concerned my entire job is to make my boss happy. It's not to second guess decisions made outside of my pay-grade.: You'll never work for me. I don't hire 'Yes Men'. I want my direct reports to offer constructive criticism when I'm about to make a suboptimal decision. If I didn't value their opinion, I wouldn't have hired them in the first place. – Jim G. May 23 '11 at 17:44
  • 7
    I disagree with this sentiment. First, if you want to be promoted, you should show that you are able and willing to take on the responsibilities of a senior position, so in that regard keeping your head down isn't good for your long term career. Second, I don't believe in the 'above my pay-grade' approach to work. Everyone is there to make the company successful (if it's not, you no longer have a job), so if you see a better way of doing anything, above your pay grade or not, you should point it out. Sometimes a new hire can make good suggestions because they have a fresh perspective. – Cercerilla May 23 '11 at 17:51
  • 6
    Have to agree with @Jim G. Having the attitude of being a "Smithers" is the worst thing you can do; thinking your manager is always right is a terrible thing because often they aren't right. Also agree with @CodeninjaTim - a new hire often has better suggestions because they don't have the same view as the longterm guys have, so they are less likely to just follow the "status quo" – Wayne Molina May 23 '11 at 17:52
  • 4
    @Jim G: It sounds like the OP has already raised his concern "This is the 3rd time in 2--3 weeks." - I can't imagine you would want to employ someone who, after voicing his opinion and being explained that A is better than B (even if he disagrees) he refuses to make the change. At that point, he really isn't 'working for you'. – Rob P. May 23 '11 at 18:15
  • 3
    @Wayne M - I'm not advocating we believe our managers are always right. I suggested raising his concerns in an appropriate fashion. But after being told to do something 3 times over the period of a few weeks, OP is not handling it correctly. By all means, voice your concerns, but realize you are EMPLOYED (unless you aren't - then ignore this). You've agreed to do work for someone else in exchange for some level of compensation. The fact that you have a boss implies an expectation that you do as you are told, within reason. Right or wrong, that's what you've signed up for as an employee – Rob P. May 23 '11 at 18:22

There's an undercurrent to all of these that I think should be brought out in clear: don't be combative. Preserve your relationship with him. It's great to take his advice with a grain of salt and validate it in books and on sites like these, but don't attack him. If he's a senior developer and has been through lots of projects, he's not an idiot, and there's lots to learn from him. As it seems like you've already done, express your desire to understand his viewpoint. Even if you're sure he's wrong and you're right, accept the possibility of the opposite (seems like you already understand this). Try to make it clear that you're arguing because you want to understand his viewpoint better, not because you're trying to prove him wrong.

If he doesn't get back to you right away when you ask him a question, or if his answer is vague and/or unhelpful, don't assume he's blowing you off. As has been mentioned here already, he may well be busy and/or stressed.

It's also great to be patient. Keep a list of things in your head that you think should be done differently, and present them at the proper time. Make sure you have justification for the suggestion besides "it's best practice." And be careful to do things right and to not make mistakes, so that you have credibility when you make your arguments later on.


So far I have been trying to avoid the issue by listening to him, raising a counter point, he raises his original point again (most of the time he will say best practice, more maintainable but just didn't go further), I... think about it at home, but... I'm still not convinced. But recently he... saw my code and asked me why haven't I changed it to his suggestion. This is the 3rd time in 2--3 weeks.

(Slightly edited for the actions.)

This part concerns me. One way you can see if you are correct or not is understanding what he is saying. What I read (with my own history, others may be different) is a junior developer not understanding what the mentor is saying, and not asking for clarification. One way you can figure it out is to ask him to clarify: how is this a better practice than that? Or Why is this more maintainable than that for our code? If you don't know his answers to this, you really don't know if he's giving good advice or not.

The part that really worries me is that he's asked you to change it multiple times, and you haven't. Here is one way it might look from his side: he requests you make the change, you ask why, he gives you a (valid, to his mind) reason, and you refuse to make the change. You don't ask for clarification, so he assumes you understand the reason, and are either too lazy or too stubborn to change it -- neither one a good thing for a senior developer to think about you. Trust me, it's much better to ask questions than to get a reputation this way.

  • I did ask for clarification, but the answer I always got back is 'it is a better practice' or something along the line before he got back to do his own things. It is 1 thing in my opinion to say it's good or better practice but what I wanted to know is 'why' it is better, which he has not been able to explain to me but to keep insist is better and as he is a senior, I should trust him. Still it is bad of me to not change despite being asked 3 times about it. – learnjourney May 24 '11 at 11:52
  • @learnjourney: I agree there is likely a problem if you are asking why and not getting answers. I would still recommend that you stay aware of what it may look like from the other side, but if this senior developer can't help you, find another and put the problem before them, with just the basic "he said <reason>, can you explain how that applies here?", and no recrimination. If that doesn't work, then I'd look to some of the other answers that say to make the change anyway, but keep your version and reasons handy. Do make sure to learn from it either way. – Caleb Huitt - cjhuitt May 24 '11 at 14:22

A few thoughts:

1/ Does it work? Is his way working or not? Is the any objective reason why his way would be inferior?

By objective reason, I mean something that can be measured without ambiguity (performance, bugs, length of code...) If his solutions work and there is no objective metric that indicate it's a poor solution, do it his way. His way is better... because it is probably more consistent with the rest of the codebase and because it will be easier for him to use/reuse your work. You might not like it, but that's not what it is about, is it?

If it does not work, or underperform on important metrics, implement it, compare his solution with your solution, then tell him that you have tried his way, but you can't get it to perform well (give the metrics) and ask him if you made a mistake in your implementation or if there is a requirement that you were not aware of

2/ Star programmers say... Why give a damn? You will find famous programmers deeply at odds with each other on many fundamental subjects such as planning, design, OOP vs procedural, unit testing, exceptions handling, source control, on and on and on.

If the only difference in workability between 2 solutions is who favors it, skip it. You might benefit from the mental workout required by working in a paradigm that you do not like


Based on the idea that you should only take advice from people you want to become like, the answer is that the senior advice is good if you want to become like him/her.


Most of my problems I have sorted by posting to forums and getting replies from others, and I have been surviving for around 1 year like this.

What should I do in such situation?

To be honest, this is what a lot of technical jobs are like. You need to be a self-starter who can solve difficult problems by yourself (with the help if the internet and it's denizens) if you have to.

From the point of view of getting code reviews and getting help with architectural designs, even when I've had good managers I've never had much of a code review beyond "static variables should be prefixed a s_".

Take the opportunity to learn and learn how to learn; those will be skill that you can use into the future.

  • Yes, that's the only optimistic thing i see in my situation. – developer123 Aug 19 '11 at 14:32

If you think for a second that management doesn't understand how capable you REALLY are to get the job done, then you are probably wrong. Management probably also understands that your lead right now would be completely useless if he replaced you and took over your work.

The REAL reasons they haven't relocated you are because despite all of your challenges that you present to them, you are still the best person for the job. They obviously value your work too much to risk handing it off to anybody else.

Don't underestimate management's intelligence...

They are a lot smarter than most developers give them credit for. I didn't understand this until I started managing. They probably also are aware of how useless your lead really is but they are probably powerless to address that problem.

Let me paint a picture for you, Lead A with 5 yrs experience at the company is incompetent. Manager knows this, recommends to his upper manager to lay off Lead A. Upper manager asks why he wasn't dealt with years ago if he is that incompetent. Manager looks bad now especially since Lead A has a bloated salary that was being paid for no benefit...

Here is another potential scenario, Lead A is close friends with somebody important. He is too hot politically to take on,

Either way, with a long running mistake like that it is easier for large organizations to sweep imcompetent people under the rug, give them busy work and fake power that is appropriate to their years of "experience" where they can't do TOO MUCH damage. Unfortunately many organizations would rather do this then actually deal with the problems.

Of course the reason for this is that the manager in this kind of organization is always better off short-term to deal with bad talent this way than to address the long term problems that these kinds of people can bring to the organization.

So while it is short-sighted and potentially unethical, you have to admit it is a little smarter than many developers actually give credit for.

  • Thanks for the answer and bringing in the management side of thinking and their viewpoints. Upvote for you. – developer123 Aug 20 '11 at 6:02

ughh ahhh. This question reminds me of many things. First all i'll say i couldn't get along with one of the managers at my last workplace. It wasn't a personality issue. It was a communication issue. I said XYZ and that specific manager would interrupt what i was saying as ABC. I would not be able to communicate well unless i worked with that manager for a more then a year.

This past weekend. A guy argued/disagreed with me about singletons. I said they are not good and should NEVER be used and absolutely no reason to use them. I linked him to http://www.gmannickg.com/?p=24 and the more in depth article it links to a few days after the argument. The day of another programmer (DudeB) mention he only uses singletons when its appropriate (which i added to with 'never'). DudeB didn't say anything about that but DudeB did say that DudeB was in a project which had memory contention because all the threads were accessing the singleton. After mentioning this, showing the article and mentioning memory contention the guy i argued with said we'll have to agree to disagree which i agreed to because i don't like talking about singletons (yet i am writing this d'oh)

Point is. Sometimes you could be dead wrong like this guy is (maybe someone will disagree about singletons with me in a comment). In my situation with my manager who was my senior programmer I just did what i was explicitly asked to do and i did not take quality seriously at that workplace ever again. I did do what i prefer to do when allowed but always did what i was asked to do but if i disagreed i would bring it up at least once.

  • 1
    Re: "maybe someone will disagree about singletons with me in a comment" - I disagree with you ;o) But lets agree to disagree – JW01 May 24 '11 at 10:09

I have a completely different/controversial opinion on this.

Often times people loose track of the end goal which for most industries its about maximizing profits and minimizing loss. I know this sounds heartless (hence the negative points) but experience and sagacity matter very little if you are not going to be producing results.

People can get caught up with extremely indirect minute things to quibble about that have very little impact on the direct results of the company.

If you think you are right about something your best bet is to show how that will produce better measurable results.

  • -1: So ridiculous. // The crux of your "controversial" opinion rests on the fact that the OP is caught up in minutiae or triviality. You don't know that! Take the question at face value. – Jim G. May 24 '11 at 11:29
  • Most Programming is minute Jim G. And from experience (I am a senior developer) there is much other B.S. involved with being right. There is almost always a bigger picture. And the people higher up respond to bigger picture (see his update), not to "but my design is more decoupled". Since the OP did not give an example I had to take some liberties. – Adam Gent May 24 '11 at 11:55

I would initially try and stick it out, at the end of the day resistance to the senior is likely to be futile at least until you gain some more experience and respect. Use this as a learning experience and in 2+ years time if you still feel the same way - move on to another company. That is when you can use a combination of your and your seniors good ideas to impress your new employer. Of course you may start to realise some of the reasons for what you perceived to be bad decisions earlier on in your career and at some point you may have a junior developer working for you.

  • 5
    -1: Why waste 2+ years working for a senior n00b? – Jim G. May 24 '11 at 11:41
  • @Jim - moving jobs after 6 months doesn't look good on your CV. If you move to somewhere else and the senior is even worse, the effect on your CV is exponentially bad! Also you might learn to realise that not everything they said was incorrect or at least there was a reason for doing it that way. – Matt Wilko May 24 '11 at 11:55
  • 1
    @Jim - While I agree in practice, Matt does have a point; people are stupid and constant job hopping trying to find a proper environment can hurt you (I can speak from experience on this one). It depends on exactly what the advice is, whether it's just not optimal (e.g. we can't do TDD or use an IoC container) or outright wrong (e.g. I don't know what an interface is or why you would ever use one in programming). The former is alright to "stick it out", the latter is where you run away screaming because the senior is an idiot (I hope I got those terms right.. they always confuse me) – Wayne Molina May 24 '11 at 12:03

[Repost: because I somehow created a second account on here]

But recently, he approached me yet again, saw my code and asked me why haven't I changed it to his suggestion.

You should be clear on whether these are suggestions or orders/instructions/directives/whatever.

Suggestion = I think it's better to do it this way; but it's your choice.

Order/etc. = I want it done this way; and it's MY choice.

If it's truly a suggestion, do as you wish and let your code stand. If it's an order (and this mentor has authority over you in this manner) - do as they say.

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