It was to talk about “team restructuring”

  • SilverCode@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    What the company likes about the old timer is that because he has been there for 10 years, he will likely be there for the next 10 years to support the complicated system he is creating now. If a younger team member creates something using a modern approach, there is the risk they will leave in a years time and no one knows how the system works.

    • JackbyDev@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      No one knows how to use a well documented, publicly available service? No, I’d argue that no one knows how to use a private, internal only, custom solution.

      • Ajen@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        That because you’re an engineer (I assume). The people signing off on these kinds of projects don’t know enough themselves, so they go to someone they trust (the old timers) to help them make the decision. The old timers don’t keep up with new tech, so we keep reinventing the wheel.

        • BoofStroke@lemm.ee
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          1 year ago

          “keeping up with new tech” is often just re-inventing the wheel. If it isn’t broke, and can still be maintained, then why break it because you like the flavor of the week?

    • So he’ll rip an even bigger hole, when he is retiring because the company never bothered to get a new solution running. Then they get a hydra of legacy code that is poorly documented and probably using some old hacks based on even older forum posts, nowhere to be found again.

      • wizardbeard@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Oh god. I do a lot of PowerShell scripting at my place, and less than half my team is proficient in it. My co-workers who are almost never write comments in their scripts. Meanwhile, if it’s anything that will live longer than ~5 manual runs, I spemd more time on comments and documentation than scripting.

        That effort is valued, but I’m shocked that my team isn’t more aware of the need for documentation. We literally experienced the “bus factor” situation a few years ago.