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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

(Slightly edited for the actions.)

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

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

A few thoughts:

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

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

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

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

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

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

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 ?

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.

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.

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.

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.

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