• pinball_wizard@lemmy.zip
      link
      fedilink
      arrow-up
      2
      ·
      5 days ago

      I feel like the guy on the right while everyone around me vibe codes things.

      It doesn’t pay (literally) to be too anti-AI, today.

      I’ll accept my trophy and bonus later, but I will feel slightly bad about it.

      • Ephera@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        5 days ago

        Yeah, same. Others will generate some awful code and get praise for how quickly they implemented a feature. And then I need to debug or modify that awful code at some point and it takes longer than rewriting it.

        It just feels so wrong, too. We had the ability to quickly write awful code beforehand, too, and learned over a long time that it’s not worth it. Now we have a different way of doing the same thing and it’s treated like it’s entirely different.

        Maybe we can shift to an entirely different paradigm, where we don’t need to understand code anymore, because we always just generate anew or something. But I’d really rather have any evidence of that being a good idea, and not just causing different bugs to be generated, before I risk a project to that.

        • pinball_wizard@lemmy.zip
          link
          fedilink
          arrow-up
          2
          ·
          5 days ago

          We had the ability to quickly write awful code beforehand, too, and learned over a long time that it’s not worth it.

          Well said. This whole hype cycle has been weird.

  • stenAanden@feddit.dk
    link
    fedilink
    arrow-up
    35
    ·
    6 days ago

    But you should actually make those tickets because it allows you to track common issues and fix greater problems with the system. Those tickets are NOT meaningless “bureaucracy”, they are a fundamental part of efficient development.

  • cheesybuddha@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    5 days ago

    Just fill out a ticket. More data about problems gives your team more tools to work with when developing solutions. If there’s a regular problem, but you fix it yourself every week instead of submitting a ticket, then it will remain an unknown problem and no permanent solution can ever be developed. It will also not be taken into account when developing new procedures or new products.

    Just fill out a ticket, please.

  • BillyClark@piefed.social
    link
    fedilink
    English
    arrow-up
    12
    ·
    6 days ago

    I once had a manager who didn’t like me because, right after he joined my team as the new manager, we were at a meeting discussing a new software service, and I said that we didn’t need to create that service because we already had a service that did the exact same thing.

    It was our main service that we supported. Every non-new person on the team knew this was a ridiculous idea.

    The manager didn’t propose the idea. It was a different new person that the manager had brought with him from his previous team. So, I shot down the obviously bad idea. But it later turned out that the new manager had already supported the new service.

    So anyways, he hated me because I unknowingly contradicted his judgement. I would have directly contradicted him had I known he supported it, anyways, because it was the wrong choice. I’m just making it clear how ridiculous the situation was and how terrible this manager is.

    So, as a result, this manager decides to work against me and gives me a lot of operations work, knowing that our metrics are biased towards commits in the code base, and that this will make me look bad come review time.

    I left his team shortly afterwards, but I can’t say that his abhorrent behavior didn’t bother me. I liked that team before he joined. Fuck that guy. And fuck metrics that don’t show the whole picture.

    The new guy who proposed the service ended up implementing it. By the way, his coding ability was worse than most of the interns we had, as well. I’m guessing that he and my manager were lovers or something, because nothing else would make sense. But at any rate, I’m sure his metrics looked awesome. Lots of commits making a completely redundant and useless service.

  • NigelFrobisher@aussie.zone
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    6 days ago

    I’ve never received a satisfactory explanation what the difference between pro-active and active is. Like, every single example usage in the dictionary you could swap in “active” without changing the meaning.

    • luciferofastora@feddit.org
      link
      fedilink
      arrow-up
      5
      ·
      5 days ago

      The emphasis is distinction from reactive. Proactive means you act before something has occurred (for example to prevent it or to prepare for its occurrence), as opposed to reactive, which is acting after the fact. If you’re fixing issues proactively, that means you anticipate that something is going to become a problem and change it, rather than waiting for it to become a problem and (reactively) fixing it.

      Of course, the difficulty with appreciating the impact of proactivity is that it changes what happens and thus makes it harder to see what might have happened otherwise. If I (proactively) replace some machine part that was close to breaking, the result (business as usual) is less visible than if I had let it break (interrupting business) and (reactively) fixed it.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      5 days ago

      The “pro-” is derived from Ancient Greek and means “earlier” or “prior”. So, “proactive” means to become active before something (typically bad) happens. It’s the opposite of “reactive”, which means to become active after something (bad) happens, i.e. in response to it.

      An example: To help with fighting fires, you can proactively remove flammable materials or buy fire extinguishers. But if a fire breaks out anyways, then you have to deal with it reactively, a.k.a. react to it, by then making use of the fire extinguishers.

      In both cases, you become active, but one time you become active before something happens (proactive), the other time you become active after something happens (reactive).
      Well, and the things you do in those situations are generally also different. Proactively, you try to prevent a catastrophe from happening and prepare remedies in case it still happens anyways. Whereas reactively, you use those remedies to condemn the damage and try to get things back into working order as quickly as possible.

      • TheUniverseandNetworks@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        5 days ago

        And of course if you fix things proactively (before they happen) then that’s likely to be expenditure which will be seen as unnecessary if/when it doesn’t happen. So:

        a) the best way to do it

        AND

        b) management will hate you for it.

        • Ephera@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          5 days ago

          Yeah, it is literally just saying “active before something happens”, so you can also omit the information that it’s “before something happens”, and therefore you do just express that you’re being “active”.