To have any hope, you have to find someone above him who

1. Cares enough to listen
2. Can think critically enough to understand the concern, even if they aren't a programmer.

If you're going to end up walking anyway, there's no harm in giving it a shot.

It should be emphisized that while the statement itself is harmless, that's not the point...the point is that it is indicative of a complete inability to do his job, and if the simple is hard, the dangerous and difficult will be impossible.

If you got on a bus, and the bus driver started trying to drive the bus before starting the engine, and was wondering why pulling the steering wheel towards him wasn't starting it, you should get off the bus, despite the fact that no damage has been done. Yet.

IMO if a technical person makes a mistake and asks not to criticise him when confronted about it this is a sign of some critical problems. Maybe that person is so occupied with some management tasks that it's hard for him to concentrate on writing code. Other reasons are possible.

You could for example suggest that another person is assigned as a reviewer for him. Reviewing code periodically doesn't require much effort but helps find such problems. This would be more proactive than making ultimatums. That person could be otherwise very valuable to the company and that's why the management doesn't do anything.

At this point you may sadly be forced to simply play CYA. Document the issues at hand as nicely as possible and circulate to whoever will listen. The real problem for you occurs when one of these potential bugs causes a very large issue in production and your proj manager points at you ("trouble" slides downhill). Looking for a new position, even in these uncertain times, may make you feel better.

Start a blog take every piece of crappy code make a similar example blog about why it is wrong and what should be done correctly. Then after you have 20 or 30 posts on getting a clue about programming send the guy a link to the blog in an email saying read learn enjoy. The other option is to just mock him openly for being stupid.

Since you've spoken to management, they apparently value his opinion/expertise more than yours. You have two choices:

a) go up the food chain. Someone higher may be more interested in programmer health.
b) Move on. They obviously don't give a crap and they're just going to bring you down with them.

EDIT: Since you're a contractor, you have two different choices:

a) If you like the work (and/or need the money really badly), suck it up and deal with it. Sometimes you have to work with a-holes who have no excuse. That's life.
b) If the work is alright but they're still driving you nuts, keep looking. When you have an out, get out.

Bottom line, if management is not willing to recognize this person as a detriment to the team, then you, as a contractor, are not going to have much say in the matter. It sounds like you've done all you can without causing pain to yourself. Pushing harder is probably not going to make it any better.

Does the IDE warn about this? That might be a good place to start, as it would be an outside influence saying that something is wrong.

In the end, though, you need to pick your battles. I have been in similar situations, where teammates' sloppiness got on my nerves (I would define 'sloppiness' as this sort of thing, which doesn't break the code, but is just embarrassing to look at). I raised the issue, and tried to get them to fix it. In most cases, they say they agree with me, and perhaps fix that one occurrence, but then it happens again.

In the end, I can to the realization that not everyone is as OCD about these types of things as I am, and my energy is better spent worrying about the functionality and maintainability of the code.

The bigger problem, though, is his unwillingness to accept criticism. I would definitely bring that higher up the food chain, and if no one is responsive, look for another job.

One thought first ... there's various kinds of wrong.

a = 7;

a = a;

b = a;

May be dumb but it's not actually harmful. The code will probably pass most tests you throw at it. It shows some level of confusion, but if in the end the actual app works how concerned should you be? [Personally I'd hate the accuring technical debt, but maybe not enough to resign withut having a new job to go to.]

I infer that things are worse than this. Code is actually working "accidentally" relying on unspecified language behaviours such as the contents of un initialised variables. Now once again, today this code may actually work! Hence the coder somehow can't see the problem. Again pretty dumb, but a different more dangerous kind of dumb. In such cases I would expect to see compiler (or lint or whatever) warnings. If the team policy is not to clear such warnings then perhaps this is a general issue that could be addressed, "Hey team should we ..." depersonalising the discussion.

Which leads me to point two: presentation of such issues, especially when dealing with overly defensive folks, is really tricky. [Must admit to many failures of my own on this.] For future reference, consider whether you could have elicited a better response if you presented the problem in a different way ... Is the idea of this line to initialise a to zero? Would it be clearer to write " a = 0" ... [subtle as a brick that one ;-]

As to what to do now. Big question: can you work effectively in this environment? Can you produce your own deliverables and can your team overall get the work out? Perhaps with some fixes of the errors you see? If not, then I would start looking for a move. The organisation sounds pretty dysfunctional, and as you've tried change from the bottom and not made much progress I think you're heading for a really bad time.

On the other hand ... If you can be effective, you could choose to stick around and influence the things you can do. As your track-record is seen you may have more voice, perhaps eventually you find a opprtunity to grow a sub-team of your own and do it right.

I think the biggest mistake you made is to try to explain why this is wrong instead of asking him what does this line do. I wasn't there so I don't exactly know how it happened, but you should always be very careful about how you formulate questions about other people's code. People tend to get very personal about it and thus you shouldn't come first and try to prove them wrong (even if they really, plainly, absolutely are).

The thing is, if you ask him to explain this line to you now, he'll just get upset as he'll think you are just attacking him once more. You should try to make the tensions wear off a bit and then approach him in a way he can't feel attacked.

I really recommend not walking away, this is a great opportunity to learn how to manage conflict. A skill without equal for anyone who works in a company and/or aspire to be a manager one day.

This is a human issue and perhaps programmers are not the right people to answer it.

The quick answer as others have said is simply to get off the bus. However if you feel like making things better rather than just walking away then it's worth seeking some advice from someone you feel well understands headology.

Am I missing something? Is there something intrinsically wrong with your example?

a.SomeProp = a.SomeProp;

There are certainly properties where this will fall over, but there are also property implementations where this would act as a no-op, just like if a normal variable were self-assigned.

Collect some concise and clear evidence about why this is bad practice.

Send this in an email to him, and cc your team and his direct supervisor and spell out in clear, non-emotionally-charged language why it's a bad idea.

Then, move on. As some have said, pick your battles. If something like this happens in future but on a more spectacularly failure-inducing scale, you can if necessary whip out that email to cover your butt and say, "Well, I did tell you so..."

First things first - ultimatums only work if they're backed up by something. If you're trying to propose a "him or me" ultimatum, be prepared to walk.

From my perspective it looks like you've done what you can in your circumstances. That is of course assuming that you've highlighted the issue in a professional and courteous manner, plus offered suggestions instead of just telling everybody who didn't want to know how bad your team lead is as a programmer.

I would work on the assumption that while the programmer shortage might not be as bad as it's sometimes hyped and you are as good as you think you are, you might want to progress your career elsewhere. In fact given your description of the situation I wouldn't be surprised if that would be the likely outcome anyway.

He is the team leader, and you made your issues known. It is his responsibility to make sure the project implementation is successful. Don't write code like that, just do your job. Unfortunately it is harder to fire than to hire, and management might have a hard time rearranging the team, just my guess.

My advice would be to understand your enemy ^[1]. You've run afoul of the 48 Laws of Power. By pointing out his mistake (Law #1), and then by trying to convince him through argument (Law #9). It might be too late to mend things (see Law 14) and now he might think you're a know-it-all (Law 46).

I use the 48 Laws as a way to remind myself that individual people have different motivations and personalities. You can be absolutely right and still end up in the doghouse or even fired. However irrational human psychology can be, it is essential to communication. Not everyone responds to a logical argument so you will be hitting a brick wall if you stick with logic. Communication using emotional arguments may seem pointless but if they speak to the other persons mentality, it is still effective communication.

This is very interesting especially since the issue is about me. I only wish the link to this was sent to me at the time and I might have understood better and had more empathy towards leppie. We are only human and make mistakes and struggle sometimes, so I always tried to promote peer level team work with no finger pointing and to help each other out. Some developers are exceptionally talented, but can be arrogant, self-righteous and disrespectful to the team about it. For instance, when I wanted to observe leppe working (in an extreme programming way), he said anyone who wanted to watch him work would have to pay. This is a human issue as these sorts of people, although seemingly valuable, can be very destructive to the team to the point that no one would actually want to work with them. Management should in fact rather let them go because they cause more harm than good. I have since left the company and moved on to another opportunity where the people are more congenial. I certainly have learned a few things about this and will put this down to experience and try not to make the same mistakes again.

Watch out, he's screwing with your head! Clearly a.SomeProp = a.SomeProp accomplishes nothing, but is a VALID expression in some languages. Is there a reason for you to think he's targeting you for something? It is virtually unthinkable that he would NOT KNOW what that statement does or why it is wrong

He is just to stubborn to actually even consider that he might be wrong. I bet if he even thought about it for a second he would realize he was wrong.

Good to see the comment of Team Leader above. I was curious running through this old thread if there's any single answer like 'let the leader do his job and keep doing yours'. No any. Developers are in no concern geious, most of them. Still it means NOTHING since their efforts are rather directed to create things but not to achieve project goal. That's all about manager and lead to actually direct development to make the project happen and succeed. And yes, leader SHOULD restrict and suppress developers' freedom in order to make these genious people work together.

Now, blames and negatives welcome :)