in reply to poor quality perl code

If you are the team leader, then you can (with management approval) develop coding standards that are to be used by all members of your team, and you can also reconcile those standards with the leaders of other teams.   If you are not the team leader, then you should privately discuss your concerns with him or her – without naming names.   It is not your place to “tell them” anything at all, and your perspective just might be ill-advised in ways that (in your earnest sincerity) did not occur to you.

But also – and this comes from a lifetime of working with “legacy code” and older, recalcitrant projects – do not change existing code just because you think it’s ugly:   “stick to your assigned ticket,” and do exactly what is necessary to fulfill the requirements of that ticket.   No more, no less.   If you think that something ought to be changed, and for more than just cosmetic taste, then you should open another ticket specifically identifying the section(s) and what you think should be done to them and why.   But do not then commence work on your new ticket unless and until it is approved by the team leader.   Always perform the work, if assigned, on a separate, assigned git branch, and do not merge it until after it has been code-reviewed by a peer and by the team lead.

The reasons for my saying these things are more than simply political – they are technical.   Generally, programmers (of necessity) are focused very closely on one small part of a massive piece of source-code; not the whole thing.   But there are others, including team-leaders and higher, who are.   There should be UAT (user acceptance testing), compliance testing, and possibly many other things – all upstream from you and maybe unknown to you.   Your actions, sincere though they might be, could be harmful in ways that you are not aware of.   IBM had a term for these kinds of changes – HIPER = HIghly PERvasive.

Replies are listed 'Best First'.
Re^2: poor quality perl code
by Your Mother (Bishop) on Mar 22, 2018 at 15:01 UTC
    It is not your place to “tell them” anything at all, and your perspective just might be ill-advised…

    Classic sundialsvc4.

      Actually, I didn’t intend that comment to be “as asshole as it may have sounded.”   :-D   When you have put together a team of people to help maintain a piece of old source-code (and this is virtually my entire experience) then one of the problems that you face is that – “the source code ... basically all of it ... Sucks Large.™”   Yes, it does.   And so, everyone wants to “fix it.”   They have their own notions, and they are probably entirely accustomed to the idea that they simply have the liberty to exercise those notions – to “fix it.”   But to make the whole process actually move forward I think that you really do need to have a rigorous command-structure that stretches quite a bit higher-up than any individual software developer sees, or needs to see.   However, this means that the individual programmers need to be made to realize that the hierarchy is there for a reason and that they need to follow it.   This might be a very-new mode of thought to some of them.

      There are, of course, strong egos at play here – these are, after all, race horses – but I did try to say in a later paragraph that my reasons were technical as well as political / HR.   The opinion that “code is not being written as it should be” should be treated as valid, but scrupulously handled within the established process and never as an exception to it.   Hence also my admonitions to stick strictly to tickets and not to add-in unrelated changes merely because you can’t stand the way that one particular thing smells.   (It all smells ... that’s why we’re here.)   Contribute to the process, move it forward, but voluntarily choose to assume that you have a narrow role in it unless otherwise stated.   Believe it or not, others will appreciate you for doing that.

      Seriously – on a big project, you might, with the utter best of intentions and in what you thought to be your best (albeit, independent) judgment and (you assumed) discretion ... unintentionally create a Great Big Mess!   Such that you would, of course, be horrified to learn that you had done so.   Well, so it goes.

        The quote wasn't highlighted to make you sound like a bad guy, just an unconsciously ironic one.

      A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: poor quality perl code
by Anonymous Monk on Mar 22, 2018 at 12:30 UTC
    from the guy who constantly posts code that doesn't even run, advice and assumptions that are simply wrong. troll on.