views:

1858

answers:

18

What do you do when your team leader does not know why the following is wrong:

a.SomeProp = a.SomeProp; // no funny side-effects, plain old property

He claims 15 years of programming experience, and 7 years of C#/.NET.

To me, someone of 3-6 months experience should know this.

What I have done:

  1. Tried to make him understand why it is wrong. He told me not to criticize him.
  2. Told him it's not about criticism, but project risk. He got upset with me.
  3. I have addressed the risk of this person with our manager (few weeks back).
  4. I have addressed my concerns with this person with our manager several times, since 1 month after I started there (7 months now).

Currently, I just feel like just not going back to work... I hardly have any nails left, and this is really just the tip of the iceberg.

As nothing has changed after I have spoken to the manager for the last 6 months, I feel like I need to make some sort of ultimatum.

Do you have any suggestions?

PS: Please do not make this subjective. I have no need for arguing. The level of incompetence is pretty clear. I just need some advice before going insane.

Update:

Thanks for all the answers (trying to update before close, buggers). I think I will forward this thread to our manager :)

Update 2:

I sent my manager another mail with my concerns, and a link to this question. Awaiting response.

+2  A: 

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.

Otávio Décio
+6  A: 

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.

Michael Todd
I know the manager is on 'my side', but I am a contractor, while he is permanent. I wouldn't mind if he would just do something else, besides touching the code.
leppie
That's different.
Michael Todd
If management doesn't give a crap, you don't need to either. Just do what you can and cash your paychecks while you look for a saner place.
David Thornley
+13  A: 

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.

sharptooth
He completely ignores all his management task. Have not seen a bug entered by him in more than 6 weeks. He will delegate taks to me although I am overworked as is.
leppie
For some people, arrogance knows no bounds. He's so wrapped up in being right, _especially_ when he's wrong, that he can't see his own ineptitude.
Michael Todd
Maybe he just likes to be a jerk to contractors.
databyss
+8  A: 

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.

Erin
Seems like this is a real good way to get fired for insubordination.
Matthew Jones
+1 I love Guerilla tactics!
DR
If you have a problem with a manager, you almost always lose even if you are right. Either accept it or look for another opportunity.
Gamecat
Almost +1 for being amusing, however I feel the need to say that this seems like really bad advice. ;) On the other hand, keeping a log of times when the problems occurred is a great idea if you might be dealing with a real shark. For instance, a time could come when something goes horribly wrong and this guy tries to throw you under the bus. That's when you remind management about your complaints, which you would also document of course. And then you could whip out the log.
Brian MacKay
+5  A: 

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.

pkaeding
Unfortunately not, I wish it did! And this is not sloppy, as he did not know what is wrong with it in the first place.
leppie
+8  A: 

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.

shambleh
+1: Absolutely right, especially if he's a political animal. He very well may try to throw the guy who points out his flaws all the time under the bus.
Brian MacKay
+3  A: 

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

Darth Continent
+2  A: 

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.

Timo Geusch
I am prepared to walk, without even having another job lined up. Thats how bad it is.
leppie
Have you worked out how to prevent getting hired by a similar shop again? There is no point in walking out of this place only to end up in a similar place again, because it'll just frustrate you and start the cycle all over again.
Timo Geusch
+4  A: 

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.

Michael Burr
I wonder if maybe the guy is just being neurotic, or maybe in school he got into the habit of doing this? Some people have weird quirks that can translate into weird practices in their code...
Darth Continent
The problem is that he does not understand that it is a no-op. He thinks something is happening AFAICS.
leppie
Why on earth would it be okay to have this code even if it is no-op? It doesn't break things in this case, so it's okay?
Beska
I never said the code was great style or useful (I did say it would often be a no-op) - the question was presented in a way that made me think I was missing something. There's often a difference between 'wrong' and 'doesn't do anything'. In fact, if you remove the restriction that there be no side effects, then self-assignment can actually do something useful (though it would still probably be bad style and not the best way to architect something).
Michael Burr
I guess...I mean, if it doesn't do anything (no side effects), it's bad because it clutters up code for no reason. If it does do something during assignment (there's some kind of get or set property side effect) that's horrible too, because it's really unclear that that's what's going on. The first option is worse though, because it indicates that the person simply *does* *not* *understand* *what* *they* *are* *doing*. The second option, you might be able to convince them that it's just not a great idea.
Beska
Like I said - I'm not saying it's an example of fine code. But given the original question (before various comments) it's unclear what the team lead might have been after - remember that a one-liner example doesn't always tell the whole story. Maybe the lead was saying "properties without side effects should be constructed in such as way that self-assignment is harmless". That's a perfectly reasonable position.
Michael Burr
Think of an example (assuming C#) where ref1 and ref2 may or may not refer to the same object - in that case "ref1.prop = ref2.prop" is a reasonable expression that might result in self-assignment, so it had better be harmless.
Michael Burr
I guess. I think you're giving the guy too much credit. Sure, discretion is the better part of valor, but this *reeks* of code smell. If I was to write a statement like this for that reason, I would fully expect people to challenge me on it, and so I would comment it with exactly why I was doing it and what I was hoping to get out of it.
Beska
(Though I like your line of thought...to examine the unusual possibilities about why it's possible that it could have been intentional...I just don't think it is here.)
Beska
When starting up this answer/thread I didn't think that there was literally code as in the questions's example - I thought it was one of those 'just an example' things where something might have gotten lost in translation.
Michael Burr
+5  A: 

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.

djna
I know it's not harmful, but he does not seem to know what he is doing generally.
leppie
+44  A: 

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.

Beska
+1 for bus story :)
leppie
+1 for the bus story, too.
Moayad Mardini
Just for the bus story, I'll give you the answer. Sums it up pretty well. If you cant put your trust in the one that is suppose to guide you, who can you trust?
leppie
Hope that you aren't thrown under the bus prior to the crash.
Darth Continent
related to the bus story is Jim Collin's principle for Good to Great - First Who, Then What (relating to who you want on the bus!) - http://www.jimcollins.com/media_topics/first-who.html
pageman
Fantastic quote: "and if the simple is hard, the dangerous and difficult will be impossible. "
matt b
+1  A: 

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

ennuikiller
I think maybe he is trying to recycle LOC :) Well TFS says that anyways!
leppie
Maybe he thinks it does something like good old "xor eax, eax" :D
vobject
+4  A: 

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.

LRE
I understand what you mean, however, other programmers are my peers, and their opinion counts too.
leppie
+5  A: 

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.

Gab Royer
That is exactly what I asked him. What do you think that line does? He looked at my blankly. Then I asked if he knows why that is wrong. And you know the rest. I make a point of not just telling someone the answer, I want the person to understand.
leppie
As I said, I wasn't there so I don't know what happened exactly, but it does seems he went on the defensive. You should be very careful about how you formulate things to prevent such things. You should also be extra careful with correcting people who claims to have a lot of experience or are higher than you in the hierarchy. As those can sometime be more easily offended (as I learned to my own demise). Not saying you shouldn't correct them, not at all, just saying you should probably put extra attention to your formulation in those cases.
Gab Royer
A: 

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.

akway
+2  A: 

My advice would be to understand your enemy. 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.

Kelly French
+2  A: 

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.

teamLeader
It is always good to see what the other side has to say. What do you say for your defence regarding the real issue = the statement that you are an incompetent programmer? Did the a.P = a.P really happen or is this made-up by the arrogant unsubordinate leppie?
Marek
This did happen and if I recall it had to do with setting some dependency.
teamLeader
A: 

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 :)

Vitaly
Wow, I never noticed that it was the actual 'team leader' that replied.
leppie