Issues with team leader on client site

[Wanderer]

I know commented code is bad practice because it encourages poor coding. Code should be self-documenting.

Too right. If it was difficult to code then it should be difficult to understand too!

[SpontaneousOrder]

Re " I know commented code is bad practice because it encourages poor coding" absolute and utter bollocks.

I suspect that the OP means that code commenting should be unnecessary, 99.9% of the time, and can be used to excuse poor quality code - rather than code comments encourage bad code per se (although i can see how that logic would work too).

I like to see zero comments outside of a public api. It has to be a very special situation to require them (at least in a fairly expressive language like c/java etc) - typically I find myself encountering legacy code and refactoring one method into 4 smaller ones and deleting the inline comment on the way.

[kal]

Re " I know commented code is bad practice because it encourages poor coding" absolute and utter bollocks.

Comments in code should be the exception not the norm, the problem with comments is that most add little value and become stale as the code evolves and maintainers forget to modify the comments.

Comments like this are useless (and serve only to get code past whatever code policing tool the project is using):

/** The ID of the user */
private Long userId;

/** Method does something and then does something else */
public void doSomthing(){...}

In both cases the code should be enough for me to work out what is happening.

Same applies with code coverage where getters and setters are tested just so some random %age target set by the code police is attained.

[wonderboy]

I feel your pain. Sometimes it's a curse to actually care about doing a job well. I think the best course of action is to try and understand the root of her behaviour. It is probably a mix of conscious incompetence, worry, and poor communication skills. Incompetence often results in bold yet meaningless gestures (like the code commenting request). The fact that you interpreted this as a demand highlights poor comms skills.

Knowing the above should help you do the right thing and reframe your interactions with her - but I am a realist and doing so in practise can take superhuman effort for some personality types.

The correct frame is one of disarming honesty, lack of emotion and assertive rather than aggressive communication. Achieving this is easier for some than others because it requires letting go of personal opinions as fast as they form and doing it well requires a suppression of your own insecurities.

It is a kind of meta-politics because by behaving in this way, even if you 'lose' an argument, you will still 'win' by being seen as a moderate when others are seen as live-wires or overly emotional.

The problem comes when your brain is wired like mine, such that you believe you form opinions based on sound reasoning from facts. The result is that when a disagreement occurs I tend to over-argue my case, actually weakening my position.

The issue is compounded if you have a "type A" personality and feel that your opinion should actually be listened to and considered. Recognise instead, that you are dealing with humans and that means that you should count actually being listened-to as a rare treat. People see and hear what they want to (cliched but repeatedly proven), making direct confrontation of an issue usually fail.

If you want to avoid ridiculous demands like the commenting thing you'd probably do better asking about her son's sports-day than explaining (as other commenters have) why commenting should be sparse in a codebase.

This kind of thing wants to make me a misanthrope, but occasionally I see this behaviour in myself and so I don't take the hatred too far...

[GrumpyContractor]

keep calm, and carry on invoicing.

This.

But i do feel your pain.

The old septic tank effect

[TheFaQQer]

Anyone in similar situation and can offer advice?

Leave. Or stay and stuck it up.

HTH

[GazCol]

Document everything ready for your handover, keep your head down, keep invoicing.

[lukemg]

WTAS - All work can be a struggle if you care too much but it's x10 if you are contracting.
Unless they have hired you to run the shop and make all the decisions, then someone else is going to and if you want to stay, I advise you fit in around that.
First priority for almost all workers is to look good to seniors, again x10 for any consultant/semi-temporary resource (e.g. contractor). This is quite simply to keep the money train running.
I see putting up with annoying people as part of the reason I get paid a lot, this means I suppress the anger and absorb the stress of dealing with them instead of rowing or chinning them.
You could sack it and go somewhere else but IME you are just as likely to find some nobber at the new place.
I am virtually financially independent after a number of years effort to make sure I am. This makes me immune from having to put up with work I really can't stand, or taking a job I don't want, or working away from home.
This feels good and I suggest all contractors make this their aim...

[Contreras]

"Self-documenting", my arse...

Requirements change, memories fade, and what is self-evident today can become unfathomable over time. Code comments are essential for a variety of reasons. In my mind the most useful of these being:

1. what the programmer expected it to do.
2. why they chose to do it that way.
3. known bugs, limitations, todo's...

...because this is the knowledge that will save me time maintaining the code.

If you want to know what the code does then use the source luke.

</rant>

To the OP, I can't add much to what's been said already.
- Offer your professional opinion but don't get emotionally involved.
- Keep a log of issues, so if ever needed you can justify the time spent acheiving nothing.
- Stay calm & keep invoicing.

If you're losing your cool then may be better to quit on good terms and be invited back at a later date to clear up the mess.

[SpontaneousOrder]

Requirements change, memories fade, and what is self-evident today can become unfathomable over time

They aren't really self-documenting then, are they? Most of the time one CAN write self-describing code.

public SomeObject doSomeWork(SomeInput input) {

Do a load of stuff with the input;
And some more stuff;

// Make sure we set someOtherProperty in the case that the input item is a certain thing.
for(SomeItem item : input) {
  if(item.getSomeProperty() > 5) {
    item.setSomeDifferentProperty("we did some special stuff to this one!");
  }
}


SomeObject obj = doSomeMoreStuff;
return obj;
}

Or...

public SomeObject doSomeWork(SomeInput input) {

Do a load of stuff with the input;
And some more stuff;

setThatSpecialValueWhereInputItemsAreSpecial(input);

SomeObject obj = doSomeMoreStuff;
return obj;
}


private void setThatSpecialValueWhereInputItemsAreSpecial(SomeInput input) {
  for(SomeItem item : input) {
    if(item.getSomeProperty() > 5) {
      item.setSomeDifferentProperty("we did some special stuff to this one!");
    }
  }
}

99% of comments are unnecessary in this way.