• MashedTech@lemmy.worldOP
      link
      fedilink
      arrow-up
      21
      ·
      3 months ago

      That’s true, never make impactful decisions in a rush. But I feel like the last panel only works in the current context of escalating code changes

    • frezik
      link
      fedilink
      arrow-up
      4
      ·
      3 months ago

      Valid, but if it needs to be decided, then there should be something concrete scheduled to do that followup when people are back in.

        • spacecadet@lemm.ee
          link
          fedilink
          arrow-up
          4
          ·
          3 months ago

          Because your dipshit Director, who came from a consulting firm like BCG or McKenzie and who couldn’t manage to throw together a “Hello, world” script in python now believes he is an expert in all tech because he read a medium article by a boot camp grad of some 8 week React course and thinks that giving Palantir Foundry $3 million a year to do basic ETL that was done previously by a couple junior devs is somehow “safer” than “writing custom code”, and by “custom code” I mean utilizing Apache Spark, Polars, and other open source tooling that Palantir Foundry is also utilizing, but charging you 40,000% more to use.

          • HStone32@lemmy.world
            link
            fedilink
            arrow-up
            4
            ·
            3 months ago

            you ever get the feeling that programming has gotten way too overbloated? that good old fashioned engineering has been buried under miles of industry standards, best practices, enterprise services, business methodologies, and managers trying to justify their paychecks?

            feels like a giant bubble way too overdue for a needle.

    • _NoName_@lemmy.ml
      link
      fedilink
      arrow-up
      11
      ·
      3 months ago

      I think this is coming from a “plugins enshittify projects” mentality where the assumptions are:

      • code bases should be as succinct and stable as possible.
      • plugins add large amounts of unused code and obfuscate many granular aspects of program execution, increasing debug and research time.

      Seems that the author views that the above devs chose to use plugins instead of writing their own code and shot themselves in the foot by doing so. The final portion seems to suggest that the person pushing all these changes then bobs out before any of the problems caused by these changes actually get solved.