6

I work for about 18 years as a professional software developer in different roles (engineer, lead dev, architect, head of development). I had to leave my last employer because of the pandemic. I am working now as an external dev on a project together with other externals. The lead is much younger than me and doesn't want to take advice from me. He is also rejecting every single line of code I am commiting for made up reasons ("We are not doing that here that way", "Your code looks odd." - not giving any reasoning). Examples:

  • I am using a cross join with where clause, he wants an inner join - which is actually the same.
  • I am using constructor injection, he wants field injection

He rejects any argument, link and so on.

Also he wants features built in, which are probably never needed and are not ordered by the customer (violating YAGNI), but "may be useful in the future", and is coming up with those at the dailies. He is the only one allowed to review and merge code. (They think this is agile).

Superiors, which are not seeing him working or in the dev meetings, are constantly praising him. He seems also befriended with the other superiors. Other devs are much more calm on that matter and tell me "Oh, thats just the way he is".

This way, the deadline of the project will definitely not hold up and I see it coming, that he will accuse the other developers for it.

His goal is to stay in a good light at the cost of others.

So my question is, how should I deal with him without being the one, who constantly complains? How can I mitigate the situation, once the deadline comes up, that he will finger point to everyone else?

19
  • Hi Christian, welcome to the workplace stackexchange. Are you able to provide some more details about your team structure? Eg. Is your team working with Scrum or Agile? Do you have a project manager? Etc. This would help us provide better answers.
    – Enthus3d
    Jul 5 at 17:02
  • 1
    Thx @Enthus3d Team has meetings like in scrum, is using a Kanban board, but does not allow to write code before not "everything" is designed by an architecture team (so waterfall). Project manager is here. It's the first project of the team lead as a lead. Still in detail a lot is missing. Project is young. By everything I mean a lot of Word Documents, which are extensivley written, but not very well.
    – Christian
    Jul 5 at 18:45
  • @Christian sounds interesting, seems like a forming new team trying to do some agile. Thank you for clarifying.
    – Enthus3d
    Jul 5 at 18:46
  • Hi. Depending on circumstances, violating Yagni may - or may not - be a good thing. When the visibility on the far future is good enough, some kind of "we're gonna need it later" is very, very useful. Of course, that's not true everywhere. But assuming the guy knows his environment, I'd give him the benefit of doubt on that topic. (the other parts of your post are worrying, don't get me wrong, especially the "He is the only one allowed to review & merge" part).
    – gazzz0x2z
    Jul 6 at 8:26
  • 5
    A "cross join with where" is not the same that an "inner join on". The result is the same, but you also need to consider code readability. They aren't rejecting your commits to sabotage you, they are just trying to enforce their code quality standards.
    – AJPerez
    Jul 6 at 23:25
5

Coding style is important within a team. It's nicer to work on a team where everyone does things the same way and your code looks like everyone else's.

If this were the other way around, you'd be complaining about a new hire wanted to do things their own way where there was no real benefit. You'd want to review their changes to make sure it was done the way you want.

What I did in a similar situation was to ask for the team's style guide, and to add stuff like this to it. A few of the rules were out of date, and I was able to persuade the team to change. Most of them didn't matter which way we did things their way or the way I was used to. In that case, the new guy has to learn to do things the same as the rest of the team.

If the style guide doesn't exist yet, this is a good opportunity to create one.

Once you've got a style guide, he can't change his mind and complain when you follow it.

how should I deal with him without being the one, who constantly complains?

Pick your battles. Ask yourself whether your way is really better, or just what you're used to.

How can I mitigate the situation, once the deadline comes up, that he will finger point to everyone else?

You can point to all the tasks that you've done, which this guy has assigned to you. If you've done what he asked you to do, in the time you agreed, to the specification you were given, then any fault must lie with the person who was controlling the process.

Your biggest risk is that he could accuse you of not doing what you are asked, and constantly arguing. Don't be that person.

4
  • 1
    "Your biggest risk is that he could accuse you of not doing what you are asked, and constantly arguing. Don't be that person." I decided for myself to do exactly that
    – Christian
    Jul 7 at 16:08
  • And if the style guide doesn't exist yet, this is a good opportunity to create one. Jul 7 at 17:27
  • 1
    @mattfreake - good point, I've added it. Jul 8 at 7:31
  • "Your biggest risk is that he could accuse you of not doing what you are asked" While I'm aware this is anecdotal and not indicative of all situations: Back up your tickets you work on (unless your tool has a proper change history and is not easily overwritten). In multiple companies, I've seen nightmare devs/PMs retroactively change the content of tickets (both adding and removing) to argue that something should(n't) have been done by now.
    – Flater
    Jul 8 at 12:03
2

Possible Alternatives You Could Explore:

So my question is, how should I deal with him

Perhaps you could start thinking of your team lead as a person with their own ambitions and worries, and not just a 'jerk'. It's hard to not be a jerk back to someone you perceive as a 'jerk', but if you can sympathize with them on 'why' they do what they do, it will be easier for you to have a better working relationship with them.

In this case, the team lead may just feel threatened or anxious about doing a good job. With this understanding, you could improve your interaction with them. In time, rather than 'dealing' with them you could end up 'working', or 'cooperating' with them instead.

without being the one, who constantly complains?

Perhaps you could debate whether you can have some forgiveness for the processes in the new team as well. There are bound to be a lot of failings in a new and forming project or team, having a bit of forgiveness both for yourself and the team and suggesting small, good, incremental improvements would be easier. Not to mention you'll lose less hair over it. Over time, your team will surely improve.

How can I mitigate the situation, once the deadline comes up, that he will finger point to everyone else?

About your fear of being blamed along with the team for bad project performance. On this point, perhaps you could stay positive, be a good role model, and maintain good relations. In the best case, this would result in your team also returning goodwill and becoming more harmonious. Less blame will be attributed, and more focus would be put on how to improve (this is the Agile way).

In the real world, though, things happen to new teams and projects. If conversely, your team is still blamed for bad performance, in this case you will have a good enough reputation to stay clear. If the team sinks, you have good enough references to move on to a non-waterfall company.


Hope this answer is useful to you, best of luck!

Edit: Deleted part of the analysis in the answer. Viewable in the edits.

5
  • 1
    Thank you very much. I think I can take out a lot of your suggestions and I will consider them definitely the next time
    – Christian
    Jul 5 at 19:31
  • 1
    To clarify: Project is going on for about 5 months and I joined 2 months ago.
    – Christian
    Jul 5 at 19:33
  • 1
    @Christian no problem :). I get a lot of stress when doing my job sometimes, hope my answer helps you lower the stress from yours :P
    – Enthus3d
    Jul 5 at 19:40
  • @christian so you come in new to an established team and say that they do everything wrong? Jul 7 at 14:10
  • No, definitely not everything. Some things are quite good done. But there are definitely some things, especially on the cultural level, which could improve a lot.
    – Christian
    Jul 7 at 16:00
1

You are very experienced, but you have been only working there for only 2 months, so you are new to the company and to the project.

I am using a cross join with where clause, he wants an inner join - which is actually the same.

Yes it's the same, but it's a question of style, I for example hate when people do select's like this:

SELECT p.name, c.name FROM product p INNER JOIN category c WHERE p.category_id = c.id

I prefer do them like this:

SELECT p.name, c.name FROM product p, category c WHERE p.category_id = c.id

And if I see someone on my team doing it that way, I won't reject their code but I will tell them that I prefer my way. ( Why? I don't know I just like it like that )

I am using constructor injection, he wants field injection

It's also a "style" preference, although I don't understand it.

What I want to say with this, is don't bother yourself with style wars, if he wants an inner join use an inner join, if he wants field injection give him field injection.

Also he wants features built in, which are probably never needed and are not ordered by the customer (violating YAGNI), but "may be useful in the future", and is coming up with those at the dailies.

Again, maybe he knows the customer better than you? After some time working with the same customer over and over again you start to get the feeling for what they are going to ask or need. I've been accused of that by my colleagues and even my bosses sometimes, and then a couple of weeks later I was given reason by exactly the same people that were saying I was wasting my time ( I don't go overboard of course, I don't spend weeks or even days developing something that wasn't asked )

The rest, unfortunately I have to say that I don't really like, don't like that he is the only one allowed to review and merge code.

His goal is to stay in a good light at the cost of others.

This is the worst for me, he's not a good team lead. And it would worry me if it's truly like that.

If he has his superiors completely blind from the truth it's going to be hard to not take the blame for the delay of the project.

But if that happens, and you seem to be an honest guy, be honest, explain what happened to the people above you ( and here you have your 18 years of experience behind you to back you up ), if they don't listen to you and don't understand why it happened, then you will know that it's time to find something better.

4
  • Thank you for your answer. As said in other comments, its temporary. And it's not the matter of style, that bothers me. It's, that the developers (team) come to a conclusion, and all of a sudden he changes his mind and does quite always just the plain opposite. Especially, he downplays every argument coming from me and quite never experienced such oppostion. At least he should be able to explain conclusively why he wants feature X or style A. And furthermore, he should give that information upfront, not during code review.
    – Christian
    Jul 7 at 8:27
  • I think, what bothers me the most, is his rudeness - but thats maybe cultural.
    – Christian
    Jul 7 at 8:28
  • 1
    @Christian, if he keeps changing it's mind, yeah it sucks and I understand your frustration, but he is the team lead so he has the authority to do it. I agree that we should explain it, but that's because of my management style I like to get a consensus from everybody on the team, he clearly has a different view. If it's temporary I would say so your best to integrate and that's it. Nothing really more you can do except leaving I think.
    – Tio
    Jul 7 at 12:21
  • SELECT p.name, c.name FROM product p, category c [...] looks wery much like a CROSS JOIN. That's why the ON clause was invented that stands directly next to the JOIN. Jul 7 at 16:12
1

I've been in your situation, and the most likely reason for this is that he is feeling extremely insecure.

It often happens in this industry that a young developer with good technical skills but not much experience of how things are done outside his company gets promoted to 'lead'. When such a person finds a person with more experience than them, they can either 1) treat that person as a great resource to improve the company's coding or 2) reject everything they bring in case it makes them look bad. Your lead has chosen option 2.

Confrontation is not going to work here. They are the lead. They currently have the trust of management and you don't. In a head-to-head battle you are going to lose.

The main thing is to keep making your suggestions for improvements, or taking his recommendations, without appearing confrontational. So when he suggests using an inner join "instead of" a cross join, say "that's essentially the same thing in this case, so no problem". If he wants a "just in case" feature added say "I find that adding new features before you need them isn't cost effective, but if you really want it done I can do it. It will take n more days."

Try to have conversations like this in private, so that lead guy doesn't feel he needs to keep his status up in front of the other developers.

Simultaneously have quiet and non-threatening conversations with your actual reporting manager (assuming it isn't lead guy) or with someone else higher up the orgnization. Raise your concerns without appearing to be going against him. For example "Lead guy is getting us to put features into the product that haven't been asked for yet. I've found this to be inefficient in the long run - it is company policy to do this?" If you have general 1-on-1 chats with your boss mention that lead guy seems to be rejecting all your suggestions - again without appearing to be confrontational. Your long term aim is to build your reputation as someone with experience that will help the company.

If I might add advice based on my personal experience, keep looking for a job that better fits your experience. You will end up being frustrated in a job that doesn't use your experience, and the constant sight of someone doing a worse job of leading than you could do will be very frustrating.

1
  • Thank you for your advice and understanding. I have taken the contract temporarily till end of the year, cause I lost my former client during the pandemic and the economic troubles. So I think following your advice, building up reputation and not going into battles, staying calm will be the best I can do.
    – Christian
    Jul 7 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .