9

We've recently employed a new lead dev that seems to have a problem in that his solution is always the correct solution.

On a typical day, whenever I push code up for review via pull request, every single ticket I work on, he has something that has to change which doubles the amount of time of each ticket.

I'd be fine with this if the other 2 developers also think he's a bit of a headache in terms of his opinion but a lot of the time, there is always.. ALWAYS something that has to change because his method is better than mine.

For example, just now I pushed up some code that literally just adds in the user's email to the view which is already in the store for that action/effect anyway. I added one line of HTML.

He comments saying that I need to change the way it gets the email by doing a different request in the effect, to get the current user id, and from that match it against the email address, and THEN display it in the view.

This ticket took me 5 minutes. He's making me make it 30-60 minutes (to understand his requirement and implement it).

Is this normal? Am I over reacting?

Opinions please!

Comments
  • 4
    It's normal for a lead to have a strong opinion but it shouldn't be normal for a lead to be retarded
  • 3
    Welcome to Office Politics 101
  • 2
    I used to play out business requirements (shortness of time) against nitpicky requirements for the 'cleanest' '(read: prematurely optimized) solution. Or proved through lengthy dialogue that it was just a matter of preference.

    I'm done with arguing about such demands. If it's what my lead wants then I'll do it and when he complains afterwards that it took too long/ or that I'm not motivated, I have a ready answer that will boomerang him in the face.

    You reap what you sow.
  • 2
    Difficult to say without knowing the details. I've seen plenty of 5 min fixes (sometimes known as hacks) which do the job but are going to cause problems down the line. Someone even cast away const on a parameter once so they could return data out because they couldn't be arsed to do it correctly. I could see they were really pissed when I told them to redo it. I'm sure yours is fine though!!
  • 2
    Based on your example, If I understand correctly, you've added new functionality on top of existing and dodgy implementation?

    If that is the case, this are two separate tasks, imho. One to improve current implementation and another to add new functionality.

    So I guess just create additional task and let him know it will take longer?

    Also make the task for the reason, so that you have someting to show, if someone tries to critisize, why it took so long?

    Maybe he knows that and wants to improve dodgy code along the way?
  • 0
    You can also think of the other side. That your tech lead maybe power tripping you and trying to discredit you. In short, doesn't like you. Wants to get rid of you.
  • 1
    I'm on the side that if you're touching a piece of code, leave it in correct state, even if it was not part of your initial task. But do it as a separate task. Be aware of premature and over optimization.
    Whether this appliies to your case, I don't know.
Add Comment