265

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?

yannis
  • 39,547
  • 40
  • 183
  • 216
learnjourney
  • 301
  • 2
  • 4
  • 10
  • +1 great question. I'm struggling with this same situation right now. – Joshua Smith May 23 '11 at 16:56
  • [A piece of steak](http://www.jacklondons.net/apieceofsteak.html) came to mind... Obviously offtopic... – duros May 23 '11 at 17:43
  • 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
  • 5
    Yes we all think we know best (especially when we are young but even when we are old and crotchety). In the end the senior makes the call because it is the senior that will get the largest chunk taken from his butt if you fail. – Martin York May 23 '11 at 18:17
  • 5
    Always keep in mind that just because something is in a book doesnt make it correct. On the other hand, he should be giving you some room to develop your own programming style. – GrandmasterB May 23 '11 at 18:29
  • 4
    If the senior can't give you good reasons why they are ignoring industry best practice, then get another job where the seniors are reading the same books. If you read books and blogs then you are already better than 90% of the market. If there's no market in your town, move to a better town. – kevin cline May 23 '11 at 20:32
  • 4
    There's more than one way to skin a cat, as they say. It may be that the way OP's superior wants to do things isn't the best possible approach, but most likely it will produce at least acceptable results for the company. But OP himself is *not* likely to get an acceptable result from his first job if he starts off by disagreeing with the guy in charge. Fitting in is part of the job; if you can't do that you're no use as a team player. – FumbleFingers May 23 '11 at 21:04
  • 1
    I agree with Kevin. Trust your feelings but think before you act. – narcisradu May 23 '11 at 21:40
  • 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
  • The answer may be that you simply have poor judgment and should listen to your mentor, or it may be that your mentor has poor judgment and you need to either ask superiors to be transferred or seek another job, but it's not possible to tell without details. – Jim Balter May 23 '11 at 21:52
  • 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 00:10
  • coming up with the last point does not make you nor him right. – Display Name May 24 '11 at 08:42
  • 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 08:48
  • 1
    @learnjourney: In the end you did absolutely the correct thing. Seniors don't know everything either, and software is a collaboration of effort. It's possible you've hurt a relationship with your current "mentor", but you've strengthened a relationship with a different one so it evens out. It never hurts to get an external opinion, and if your current mentor takes it personally, that is a reflection on him not you. Continue stretching your knowledge and trying new things. These are good traits. Don't get discouraged if every great idea you have doesn't get used though. – Joel Etherton May 24 '11 at 13:45
  • 6
    @learnjourney When I was a new developer, a much wiser Senior Developer once told me that it was a good idea if I left my ego at the door. It's the best advice I've ever received. If you have a different idea, then bring it up and be prepared to defend it, but if the senior person overrules it then hold your nose and just write the code the way that they want. If they won't budge on an idea then bring it up to your manager that you would like a new mentor, or find a new job. – bakoyaro May 24 '11 at 15:45
  • 2
    Hilarious post. Do you still have a job? – Trevor Boyd Smith May 24 '11 at 21:05
  • Your evaluation of the code and your colleagues are probably about right. It sounds like you strengthened a relationship with the really important guy: the one with a clue. Those are the kinds of friends you need. People move around a lot in this business, and the more friends you have, and the more capable they are, the better off you will be. In the long run, it doesn't much matter if the clueless guy doesn't like you, because you don't want to follow him anyway. But if the smart guy leaves, you may be interested in following him. – kevin cline May 25 '11 at 05:46
  • 3
    One point of your question is ambiguous, are you being _advised_ or _instructed_ to make a change? If you are instructed to do so, do it now. If merely advised, politely explaining your choice is acceptable. – Thomas Langston May 25 '11 at 14:28
  • 2
    "I don't understand why this is the correct choice." is always appropriate response if you disagree with a mentor. If the choice is significant, and one of the mentor's peers agrees with you, having your mentor and their peer discuss the choice together with you may help illuminate the issue. – Thomas Langston May 25 '11 at 14:33
  • 2
    Accusing someone senior of not knowing anything is pretty arrogant of yourself don't you think? Maybe your code is so hideous they don't think it is worth arguing about or salvaging? I mean if you can't follow simple coding guidelines, maybe the "intricacies" of your code are actually spaghetti code anti-patterns to someone more senior and they don't think your project is worth the effort to correct? I mean, my speculation isn't any more accurate than yours, right? –  Aug 19 '11 at 17:02
  • 1
    If your code has intricacies you have very good place to start improving. It should be as clear as glass. –  Aug 19 '11 at 17:07
  • 2
    Great question, but all the replies only reveal how pompous and arrogant these so-called "seniors" are, when mostly they have dull, uninteresting minds like mushy peas. The only solution is a swift punch in the throat to shut them up! More seriously though - if your "mentor" is teaching you bad habits, by all means go work somewhere else! Having no mentor is better than having an idiot to guide you. – Luke Van In Sep 10 '11 at 19:49
  • 1
    Happened to me. Working with senior developer who thinks very high of himself. Tell him in his face everything bad about his code. He takes offense and we fall out. He cannot say "Jeez, you're right, I need to actually read a few up-to-date books, why don't you become the software lead as you know more about this than I do". I hate people who take things like this personally. Unfortunately, 90% do. You cannot tell them that they are wrong because they take offense. I haven't worked with him since then. You get farther if you suck up to their ego. – siamii Dec 29 '11 at 23:50
  • 1
    @lukevanin how would you feel if a lot younger developer, who just came out of college, did a better job then you as senior developer. Would you feel **threatened**? – siamii Dec 29 '11 at 23:53
  • 2
    @bizso09 I think many seniors would be grateful for the opportunity to reduce their workload and improve their skills by working with someone who can do it better. Programmers worthy of the "senior" title will recognise and leverage whatever abilities they see in others. – Luke Van In Dec 31 '11 at 10:57

33 Answers33

232

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.

Joel Etherton
  • 11,674
  • 6
  • 45
  • 55
  • 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
  • 1
    +1, very good answer. Especially #3 and #4. I wish more juniors would understand those. –  May 23 '11 at 18:36
  • 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
  • 1
    @Rein Henrichs: Absolutely. I can't say I don't ever do this, but I do try very hard not to. I've gone so far as to make sure that my juniors know explicitly that if they ever feel I am not taking their concerns to heart they can tell me so point blank. – Joel Etherton May 23 '11 at 23:15
  • @Neil G: That's not intended to be condescending at all. I'm not directing that statement at the OP specifically, it's really a generality that can't be applied universally. I absolutely agree about earning respect, but the juniors I have always had trouble with were the ones who felt they already knew everything. – Joel Etherton May 23 '11 at 23: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
  • +1 to this. I'm a pretty good developer, but if I'm not certain of a fix I'll run it by one of the most senior devs on the project for clarification. A fair percentage of the time, my original solution turned out to be wrong because of some domain-specific factor I wasn't aware of. (Thankfully, we've got leads who are good at noticing these things, and at explaining them well. Sounds like the senior in the original question is not good at explaining.) – Mason Wheeler May 24 '11 at 00:29
  • 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 04:36
  • 1
    Are you sure you're objective? It sounds like you're sympathizing with the senior. – DistantEcho May 24 '11 at 07:56
  • 2
    @Kobi: I won't disagree at all. Many senior developers I know are prone to this lack of humility, but it is not an unearned lack of humility. I also expect a senior developer to have found methods to counter or nullify it. I always appreciate when juniors bring me down to earth with a dose of reality. And any junior willing to take the time to learn something new or bring something fresh to the table will always earn my attention, but that doesn't mean I'm going to implement his idea just because it's a good one. – Joel Etherton May 24 '11 at 10:29
  • 2
    @Niphra: I'm not sympathizing with the senior, I'm a senior. I'm simply providing a different outlook on some of the reasoning. I'm not saying there aren't bad seniors out there who make bad decisions or deal poorly with junior developers. What I am saying is that often there is a lot more to a decision than one might know from the surface. Perhaps the senior in OPs question just needs some training in how to manage expectations or explain situations. Perhaps the guy's just a tool who has no place being a senior. There were some things in OPs question that led me to believe that part ... – Joel Etherton May 24 '11 at 10:32
  • @Niphra: ... of the problem might be in the manner in which OP is addressing the senior's choices. I think the most likely thing is that between them they both have a fundamental lack of respect and communication, and until they have both I don't know that they will be able to overcome this problem. – Joel Etherton May 24 '11 at 10:33
  • 1
    @Rein Henrichs: Having re-read some of my answer, I see more clearly what you're referring to. It does sound like I'm saying I just dismiss it altogether rather than trying to explain why I've made the choice I've made. That's not ever the case for me, and I should probably edit that sentence to reflect that. I have never in my life made a decision and simply left it at "Because I said so." – Joel Etherton May 24 '11 at 12:38
  • Truly superb answer. – haylem May 25 '11 at 00:12
  • 1
    This is a great answer. I wish people could understand the key element that sometimes decisions are made that don't make sense from a purely technical standpoint, but make wonderful business sense. That's probably the hardest part for any of us to understand when we get so deep into the technical aspects of code. Example: hard-coding a feature instead of abstracting, for the sake of time, so you can focus or more crucial/more sellable parts of the app. – Jordan May 26 '11 at 20:02
  • @Jordan: I often struggle with this from a purist standpoint. I have been guilty of pushing deadlines because I want to code it perfectly. – Joel Etherton May 26 '11 at 20:33
  • And let us not forget that sometimes the best answer at the time the code was written may not be the best technique when the junior looks at it 10 years later, but no one is going to pay to rewrite working ten year old code even if it no longer is optimal. – HLGEM Oct 18 '12 at 20:59
  • 1
    I have found that some juniors have been keen to use new technologies, a see seniors dismissal of their use as being "stuck in their ways". In many of these occasions, they are not looking at the bigger picture - there **must** also be a business reason for adopting new technologies, regardless of how cool they are. – Amicable Dec 31 '12 at 02:17
  • As a "senior" I was struck by this answer because of the author's willingness to brook disagreement. What I was going to say in addition to everything else that's been said is the senior's ego can tell you an awful lot about how far you should go with your disagreement. The more steadfast and stubborn the senior is that you do it his way the less you have to gain from disagreement. I too will allow juniors to disagree with me and will praise them for better answers but heaven help me if you come to me with a gripe and not a better idea. That will be TOSSED aside, and quickly. – Raydot Jun 02 '14 at 19:16
34

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.

jzd
  • 4,166
  • 25
  • 28
  • 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 *why*s 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
  • @Daenyth: Oh yeah, the "I told you so" strategy is sure to win over support! Just kidding btw, I used to do that as a junior. I remember it not being appreciated. – Kevin May 23 '11 at 21:25
  • @Martin: Or the senior's advice was really bad. – DistantEcho May 24 '11 at 07:55
  • 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
  • @DaveE I don't think a senior necessarily has an obligation to be a mentor. If that's what you're looking for better straighten that out during the interview! – Raydot Jun 02 '14 at 19:32
  • @Dave Kaye - the OP says specifically the senior developer is *supposed* to be mentoring him. This isn't about the general obligations of senior developers to their juniors but the apparent specific obligation of one senior developer to a junior. – DaveE Jun 04 '14 at 15:37
  • @DaveE I could have put that better..."In charge of mentoring" can mean any number of things but what the OP goes on to describe sounds like much more of a supervisory role and most of the answers seem to be talking about disagreeing with a supervisor and not a mentor. That's a distinction with a very real difference. So I'm wondering if maybe the OP has the two confused and if clearing up that confusion might help. – Raydot Jun 04 '14 at 16:22
24

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.

Rein Henrichs
  • 13,112
  • 42
  • 66
  • 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
18

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.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
11

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
  • 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
11

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
11

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.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 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. –  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!" –  May 24 '11 at 05:49
  • @Thorbjørn Ravn Andersen: I agree, as long as it is occasional. – PeterAllenWebb May 24 '11 at 15:21
9

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.
Jarrod Nettles
  • 6,125
  • 2
  • 41
  • 45
9

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.

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

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.

Darknight
  • 12,209
  • 1
  • 38
  • 58
  • I think that is a terrible idea that will just get him into trouble. It is important to be a team player. – maple_shaft May 23 '11 at 17:43
  • 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? –  May 23 '11 at 21:10
7

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.

Blrfl
  • 20,235
  • 2
  • 49
  • 75
7

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.

Morgan Herlocker
  • 12,722
  • 8
  • 47
  • 78
6

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.

Jim Crandall
  • 11
  • 1
4

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.

Tim Meers
  • 111
  • 3
3

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?

ThomasW
  • 1
  • 1
  • 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. –  May 24 '11 at 13:10
2

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.

Amar Jarubula
  • 111
  • 1
  • 6
2

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.

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
1

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.

Community
  • 1
1

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
1

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.

BBlake
  • 563
  • 2
  • 11
1

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.

Dimitrios Mistriotis
  • 2,220
  • 1
  • 16
  • 26
  • 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. –  May 23 '11 at 21:16
  • I'd say Wayne left enough room in his answer Andersen's rebuttal. – C.J. 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
1

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.

Rob P.
  • 823
  • 2
  • 7
  • 11
  • 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
  • @Jim G: So if Rob P. worked for you, he would have to offer constructive criticism "to make my boss happy". I don't see what Rob P. is saying and what you are saying are necessarily different. From what the OP is saying, it sounds like Rob P. has given relevant advice. – Peter K. May 23 '11 at 17:57
  • 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
  • 1
    @CodeninjaTim - There is a difference between taking responsibility and refusing to complete a task as directed. There are plenty of times when plenty of other considerations come to the table besides, 'What is the best way to write this piece of code'. It's completely unreasonable to invite every developer to every meeting (it would be all meetings, all day). Developers, particularly junior developers, don't have all of the information needed to make high-level decisions that are often out of scope for senior devs. – Rob P. May 23 '11 at 18:18
  • 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
  • @Rob P.: *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'.*: I agree 100%. I gave you a -1 for the specified remarks. If you remove those remarks, I'll take back that -1 and agree that we're on the same page. – Jim G. May 23 '11 at 18:57
  • @Rob P.: I'm not advocating refusal to complete a task, even if the Jr. Developer is correct it's often more important that everyone is moving in the same direction than that direction being the best possible direction; I was just saying that anyone SHOULD point it out if they think they have a better way of doing things. The answer might be "no" or "not right now", and you have to be okay with that, but at least you've shown that you are capable of identifying deficiencies and suggesting ways of improving, and sometimes your suggestion could make a better product, or save time/money. – Cercerilla May 23 '11 at 19:22
1

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.

Mr. Jefferson
  • 1,361
  • 1
  • 11
  • 19
1

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.

Caleb Huitt - cjhuitt
  • 351
  • 2
  • 8
  • 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 , 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
1

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

Sylverdrag
  • 121
  • 3
1

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.

Alexander
  • 101
  • 4
0

As I understand it, your dev lead is actually just there to keep a watch on you "because leaving a developer entirely on his own would be irresponsible". But he doesn't have a clue how to actually judge your work.

Have you talked to him about it ? Maybe he's tired having to do that as well.

If you need advice and help, wouldn't it be a better and more productive solution to have a teammate work with you on your part of the project instead ?

guillaume31
  • 8,358
  • 22
  • 33
  • may be, also because he is in some other domain, this work might not have been his choice and he might have been pushed here. But at the same time, getting another team mate to work with me, is a management decision. If i tell my bosses `my work is difficult, and i need another team member` may show my incapability, where in actual it is not like that. At the same time, having arrogance as a defensive mechanism for lack of knowledge, is this a solution on his part? – developer123 Aug 19 '11 at 14:47
  • 1
    It's only human to need someone to share your thoughts and ponder your decisions with. The best solutions often come out of collaborative work. That person needn't be 100% on that part either. Anyway, if i were your boss I'd choose that over letting a knowledge silo form into you any day. – guillaume31 Aug 19 '11 at 18:40
0

It's okay to question things while doing them exactly as asked. A good senior person might not always be able to convince you of the rightness of doing things before they need to be done, for business reasons or even just for task-dependency reasons; but should take time to acknowledge your concern, admit when they have failed to address it, and touch on it at another time.

solidsnack
  • 101
  • 4
0

At my last job, I worked alongside another developer who'd only been there for a months more than me. He had some existing experience at other companies working on similar systems. He was very calm and level headed. Still, he gave me the impression that wasn't a native software developer. By "native", I mean he just sort of fell into a developer position gradually over time. You could tell that he was well read in some areas, but lacked some fundamentals. It was clear that he struggled on some seemingly simple problems. He could get the software to do what he wanted, but he just didn't "get it".

Personally, I could never get over the "my way is better because I read it in a book" mentality, which was something I openly admitted when I worked there. In many ways, my previous experience made me a bad fit for the position. I'm not sure if it was because I was "too advanced" or just on a different path.

He and I continually argued about how to do unit testing. He believed in a very white box approach, via monkey patching. I prefer black box testing supported with mocks and dependency injection. I thought his approach led to fragile tests, but I'm sure some of my opinions were swayed by my background in C#. He had always worked in Python. Who was right? Both of us? Neither of us?

Companies should be more careful when promoting developers to senior status. It is very difficult to gain enough experience at one job. A good senior developer has to know about what tools are available and how other shops handle similar problems. It wasn't until I left my first job (where I was a senior developer) that I learned how to build modern websites, properly do continuous deployment, manage source control branches, build distributed services or use NoSQL databases. You need to learn new philosophies, technologies and processes to really be a senior developer.

Ultimately, the six months he'd been there longer than me gave him the advantage. I always bent to his will and did testing his way. That's what professionals do. I was there to learn. Still, as with most not-quite-developers, he wormed his way into a management position. In less than 3 weeks, we had a meeting and I walked out with a cardboard box. Now I am glad that I was fired because that place was boring me to tears.

It wasn't an environment of self-improvement. Unfortunately, policies intended to help, start to harm productivity when followed too strictly. I'd sit there for hours waiting for others to review my code, only to get comments back about line spacing and naming conventions. When I started making suggestions contrary to policy... I suddenly became labeled a rebel, a naysayer and an instigator.

Travis Parks
  • 2,495
  • 1
  • 19
  • 23
0

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.

Adam Gent
  • 109
  • 1
  • 5
  • -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
0

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
0

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.

Matt Wilko
  • 372
  • 1
  • 8
  • 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
0

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

BIBD
  • 421
  • 3
  • 11