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

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?

share|improve this question
26  
You learn more from mistakes than successes. –  StuperUser May 23 '11 at 17:54
42  
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
135  
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
29  
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

34 Answers 34

up vote 226 down vote accepted

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.

share|improve this answer
46  
@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
41  
@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
25  
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
10  
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

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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 ?

share|improve this answer
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

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.

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer
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

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

share|improve this answer

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.

share|improve this answer

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?

share|improve this answer
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. –  Jon of All Trades May 24 '11 at 13:10

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.

share|improve this answer
5  
-1: Why waste 2+ years working for a senior n00b? –  Jim G. May 24 '11 at 11:41
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 M May 24 '11 at 12:03

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.

share|improve this answer

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.

share|improve this answer
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

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

There is a trick, one that a junior successfully pulled on me (the extremely bad tempered know-it-all senior developer):

  1. Do whatever you are asked to do, and exactly how you are asked to do it - be fantastically professional or go home,
  2. If you have (any) concerns, write them down - never assume you'll remember (true developers log everything),
  3. If possible, try to validate your concerns before raising them - it would be nice, but not necessary since you're still learning and it's the senior's job to validate or invalidate them,
  4. Find an appropriate time each week to raise these concerns, but only after you've completed the related tasks - appropriate time is when the senior looks relaxed and chatty - never ever the day before the big deadline,
  5. Try to repeat at regular intervals - and prepare to be amazed when the senior developer comes to you when you skip one - train us well and we'll be friends for life,

For extra points present your concerns as asking for help (apply to our vanity). An example:

  • Bad: "Hey, senior, how can you be senior when you've never written a unit test?"
  • Good: "Hey, senior, I'm reading up on unit tests and can't quite grasp the concept. Can you give me a few examples on our code?"

For extra extra points, always remember that from my point of view my time is extremely more valuable than yours, try to be extremely concise and precise.

That's all, young padawan.

share|improve this answer
15  
How some of the other responses got voted higher than yours and one not really relating to the question got marked as answered, I don't know. Great advice for a junior. –  Shauna May 24 '11 at 17:03
2  
@Shauna Thanx :) Joel's answer (the accepted one) apart from being a genuinely great answer, already had about 40+ votes when I wrote mine, so I guess I never actually had a chance :). Anyway, most of the discussion is great so I'm just glad to be a part of it... –  Yannis Rizos May 24 '11 at 20:55
4  
But what do you do when the senior has no clue what you are talking about, and the junior does? That's been the common scenario in my experience: Junior: "Hey, senior, I'm reading up on unit tests and can't quite grasp the concept. Can you give me a few examples on our code?" Senior: "We don't do that around here." or worse, "What are unit tests?" –  Wayne M May 26 '11 at 19:59
12  
@Wayne: Well, the "we don't do that around here" attitude is a good indicator that your experience with the company won't be as educational as it's supposed to be. Try to get out asap, before you get infected. The "what are unit tests?" scenario could actually be a good one, if the question is sincere. So many people are labeled "senior" developers without actually being qualified for it or and it's almost never their fault. The first time I was given a named role it was just for being the only man in the department, without even being close to qualified. –  Yannis Rizos May 26 '11 at 20:12
3  
@YannisRizos, or maybe "we don't do that around here" is an indicator that not everything is about best coding practices and that you have something to learn about business (for example, in many internet start-ups, shipping a product sooner and more frequently rather than shipping it 100% bug-free is usually far more beneficial to the business than spending the extra time to write and maintain unit tests -- and a senior developer is likely to know that). On the other hand, "What are unit tests" just shows that the senior developer is ignorant and not actually deserving of the title. –  Ben Lee Dec 12 '11 at 18:20

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.

share|improve this answer
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

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.

share|improve this answer

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.

share|improve this 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.

share|improve this answer

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.

share|improve this answer
6  
As a junior developer this type of dictatorship would drive me crazy. I down-voted, sorry. –  kizzx2 May 24 '11 at 16: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.

share|improve this answer
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 M 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

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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

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.

share|improve this answer
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. –  Loki Astari 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

Your Answer

 
discard

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

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