Continue of https://devrant.com/rants/2165509/...

So, its been a week since that incident and things were uneventful.

Yesterday, the "Boss" came looking for me...I was working on some legacy code they have.
He asked, "what are you doing ?"
Me, "I am working on the extraction part for module x"
He, "Show me your code!"
Me(😓), shows him.
Then he begins..."Have you even seen production grade code ? What is this naming sense ? (I was using upper and lower camel case for methods and variables)
I said, "sir, this is a naming convention used everywhere"
He, " Why are there so many useless lines in here?"
Me, "Sir, I have been testing with different lines and commenting them out, and mostly they are documentation"
He, "We have separate docs for all, no need to waste your time writing useless things into the code"
Me, 😨, "but how can anyone use my code if I don't comment or document it ?"
He, "We don;t work like that...(basically screaming)..."If you work here you follow the rules. I don't want to hear any excuses, work like you are asked to"
Me, 😡🤯, Okay...nice.
Got up and left.
Mailed him my resignation letter, CCed it to upper management, and right now preparing for an interview on next monday.

When a tech-lead says you should not comment your codes and do not document, you know where your team and the organisation is heading.
Sometimes I wonder how this person made himself a tech-lead and how did this company survived for 7 years!!
I don't know what his problem was with me, I met him for the first time in that office only(not sure if he saw the previous post, I don't care anymore).
Well, whatever, right now I am happy that I left that firm. I wish he get what he deserves.

  • 8
    Good on you for leaving, you stood up for what you believe in
  • 2
    Nicely done. So many twats as tech leads
  • 2
    @alexbrooklyn thanks man!!
  • 2
  • 3
    In fairness, I have similar feelings about code comments. If you really need comments *within* code, then your code generally isn't clear enough.

    But yes, there's no way I would have put it like that. That's a minor point in a code review, not something you storm over and scream and shout over. Good job with deciding to move on.
  • 6
    @AlmondSauce oh god not this bullshit again. There are so many things like business logic gotchas and legacy sugarcoating that just can’t be explained away by even the best architected code possible. Code can tell you the what’s and how’s but you need comments for why’s.

    While I do agree with the sentiment code should be clear enough that it shouldn’t need comments. There are some things that can be expressed only with comments.
  • 3
    @grumpyoldaf Agreed, hence the use of the word "generally" in the above. Apologies if I wasn't clear.

    The OPs line of "how can anyone else use my code if I don't comment or document it" however makes it sound like the code is unusable as-is in its entirety, which *would* be a worrying sign.

    That said, even if that is the case, there's ways and means of dealing with it in a sensible way, and the tech lead here is undoubtedly a massive arse.
  • 3
    @grumpyoldaf right, and comments are also good if something has to be done in some place because something else is done in another. Because that's what will trip up the maintenance programmer 5 years later who doesn't know the whole codebase.

    I remember an incident where I got a bug report, went through the code, and right at the point where the strange behaviour was, my predecessor had left a comment. It was because a totally different requirement kicked in, and the whole thing actually worked as specified.
  • 5
    @AlmondSauce my rule is that my comments should be meta coding. If I'm not describing why, but what, I'm doing something wrong.
  • 1
    The comments in my code was for the modules documentation like what you get when you import the modules, i.e if a person wants to use the module he would know what to pass as arguments.
    And in-case of comments they were generally
    #To-Dos, like what more I can add and what errors faced if something changes and all...I think it is necessary for better readability no matter how clear your code is!!
  • 1
    Actually... The CS you used should comply with whatever they had before you came in and some developers prefer clean, easy to understand code over comments. My current employer doesn't even allow doc blocks because there were too many cases of coders making changes and not updating comments, hence, we got a separate team dealing with docs. It works better than I thought it would. 1st, there's less on coder's mind when he does his job. 2nd, they're good rubber duckies. While it can be a challenge to rewrite something to make it readable enough to really not need the "what" comments, it's usually doable. Sometimes fun, even.

    Above said, I neither agree nor disagree with my company policy. I just say it's not that uncommon to follow "their ways".
  • 2
    I always just use the naming conventions that everyone else at the company does
Your Job Suck?
Get a Better Job
Add Comment