• Diplomjodler@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    After he found that formula for accurately and fairly assessing the impact an engineer makes, he should do anti-gravity next. Should be easy by comparison.

    • SorteKanin@feddit.dkOP
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      I was kinda baffled by this too. I like the general idea that they present (you need to pay your own long-tenured engineers higher than market rate cause they actually know more about your own system), but this idea of a formula? What, are you gonna start counting git commits? A formula sounds like a super weird way to solve that problem.

      Just look at the engineers that add value in your company and pay them a fair market rate. When someone leaves, find out what salary they get in the new job and ensure all your remaining engineers get at least that amount and adjust as you go along. Something like that perhaps.

      • haulyard@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        Counting commits is exactly the type of stuff starting to happen. linear.io for example. I’m seeing this used as a way to rank dev value under the guise of “we’re just trying to help teams improve throughput”

      • wewbull@feddit.uk
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 months ago

        Sometimes your longest serving engineers can be your biggest anchor. Good engineers are (justifyably) highly opinionated about what can be done, but sometimes it turns into “what I do works, so all other ways are wrong”. At that point the best move for them might be to go learn how somebody else does it. Wish them well, and back a different horse.

        • Lysergid@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          Though in reality, management will push back any unorthodox approaches/solutions/approaches as risk and additional losses on R&D.

      • lad@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 months ago

        The hard part is “that add value”. Not only it’s hard to measure, but highly depends on scope of what is done