7

Here's something that should be an unspoken rule in the dev space:

DON'T MAKE A LESSON OF YOUR TEAMMATE'S MISTAKES (OR WHAT YOU CONSIDER A MISTAKE).

More context:
I defined a column as `mediumText` in a Laravel app. What the asshole team lead did after seeing that in my PR, is taking that snippet and blast that out in the company dev slack channel on full display, saying - "Guys we shouldn't take more space in the database than we need to. If the value for the column would be < 255 characters please take VARCHAR not MEDIUMTEXT".

I mean, what an asshole !!! You could've told me that privately and I'd have happily changed it. The reason I did so, is to be safeguard myself from the future, in case the value length increases or decreases. Last thing I want to see in the logs is "Column size is too short for column {COLUMN}, value truncated".

But nah nah, let's take a screenshot of that snippet and `teach` everyone else what should and shouldn't be done according to your `standards`.

Fucking piece of shit team lead.

Comments
  • 1
    Was that after or before Review/Merge?
  • 3
    @thebiochemic The team merged it then pushed a commit of his own where he changed it.
  • 0
    Was it made clear that you wrote the code in the snippet?
  • 2
    @SidTheITGuy that sounds like your lead is kinda dumb...

    I mean sure, lead found an optimisation. That doesn't give them any more privilege to randomly push stuff onto main however.
    Especially not without review. Especially especially not, when they could've just review the change before it ended up there in the first place and left a comment on the merge request or the issue or whatever instead.

    Lead by example, not by punishment.
  • 1
    @Lensflare No it wasn't pointed out to others that it was me. But still, I knew it was me. Still a shitty thing to do.
  • 1
    @thebiochemic Exactly!! Tell me what changes you need and I'll do it. That's the part of the job. You listen to what your lead says.

    Don't broadcast it everyone.
  • 1
    but how do you expect everyone else to watch out for this if he doesn't broadcast it out to everyone?

    I feel like the lead here tried to do everything that was possible to avoid getting you to the current state. Aka just made the change himself and didn't call you out on it.
  • 1
    @iceb is a fucking idiot.

    Was me taking extra space in the database that much of a big deal to broadcast out to everyone? Did he care about asking me first why I took mediumText instead of varchar? What about his own mistakes? Does he make it a point to broadcast his own?

    I imagine you're the kind of employee who thanks his boss and company on LinkedIn after getting sacked from the company.
  • 1
    @SidTheITGuy Well I don't know. Does he? Does he post other things that people should watch out for?

    Sounds to me you are just taking things personally for no reason.

    That's like saying someone is an asshole for announcing "don't take piss on bed" and they are an asshole because you've done it before
  • 0
    @iceb What do you think made me post this rant out? If this was happening to all devs in my team, it would've been accepted as the 'norm' wouldn't it?

    It only happened to me, and I checked.
  • 1
    @SidTheITGuy I see. Gotcha
  • 1
    I don't see too much of an issue here. He picked an anonymous example that happened to be you, no-one knew or cared it was you, and he raised a valid point that's presumably a common mistake org wide.

    Agree he should have gone through the proper review process before merging his fix, but I don't see anything inherently wrong with just using some anonymous code as an example.
  • 0
    @iceb the thing is quite annoying regardless of the post in a slack channel.
    He could have reviewed the PR
    He could have ASKED for the reason

    And common, we are in 2023, don’t act as if this makes a huge difference.
  • 1
    I partially agree and partially disagree.

    Positive criticism should be celebrated. Nobody really wants to hear they did something wrong, but you generally benefit from it.

    Small things should be a note between programmer and reviewer. There's no need to put the magnifying glass on every little thing - it serves to do nothing but harm all involved.

    However, if one person's mistake has genuine utility in being a learning opportunity for the whole team - to correct a recurring mistake, highlight a common pitfall, etc, then it should be shared with the team. It would most likely be polite to anonymize the work, but in small teams that can be hard.
  • 0
    @jestdotty I want to offer another perspective because I've done this in the past.

    What if my thoughts were simply "Okay it's a small thing I can change quickly, i'll just quickly update it so my team can work on more pressing/interesting stuff"

    "maybe it's a good idea to make a note so everyone is aware"

    The second part is a bit up to debate depending on the circumstance but I never thought the first part could be seen as something negative
  • 1
    Your lead probably doesn’t like you if this is the case
Add Comment