• AdamEatsAss@lemmy.world
    link
    fedilink
    arrow-up
    61
    ·
    11 days ago

    It’s the new “promotion machine.” The first manager: “I saved this company x dollars using AI, promote me.” The new manager: “I increased productivity by x percent getting rid of AI, promote me.” Repeat.

  • bleistift2@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    41
    arrow-down
    2
    ·
    11 days ago

    C) Write a highly specific, custom-tailored boilerplate generator that does 80% of the work and needs only a day or two to implement.

    • petey@aussie.zone
      link
      fedilink
      arrow-up
      46
      arrow-down
      1
      ·
      11 days ago

      D) spend millions developing an AI to generate the boilerplate generator badly

    • ddplf@szmer.info
      link
      fedilink
      arrow-up
      12
      arrow-down
      1
      ·
      10 days ago

      This sounds just extremely dumb to me, as in “do something manually for 2 minutes or spend 2 days automating it”

      Also, DRY in 90% of the cases is a sham

      • bleistift2@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        5 days ago

        Completely depends on how often you need to write boilerplate code, and how error-prone it is.

        After writing hundreds of instances of ‘fetch this from the server and show an error if it doesn’t work’, I finally wrote a helper for that. It took 2 hours, shouts at me if I use it wrong, and instantly makes my classes easier to read because all the boilerplate is gone. As an added bonus, the invocation is so small that Copilot can write it error-free, which it couldn’t before.

        So fetching things is now a thing of a few seconds instead of one minute with a chance of making a mistake. I say it’s worth it.

      • Feathercrown@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        10 days ago

        DRY is usually helpful if you don’t use it in situations where you have like 2 semi-different things. If they’re actually the same and you have 3 or more then the level of abstraction is worth it almost always.

        • ddplf@szmer.info
          link
          fedilink
          arrow-up
          6
          ·
          10 days ago

          To me, there are two classifications of DRY - one I find harmful, the other very useful.

          First one resembles mathematical extractions, essentially you never allow a single chunk of code to be written twice and you create massive amounts of global util junk. This also creates some bad tight coupling.

          The other is more logical, where you only extract logic in places you want to always change together. Simple and effective.

  • bamfic@lemmy.world
    link
    fedilink
    English
    arrow-up
    32
    ·
    10 days ago

    I remember 10 years or so ago working with a guy who was trying to sell me on the wonders of Eclipse. “It writes all this boilerplate for you!” I was more interested in writing in languages that were less shit and required less boilerplate.

    • QuazarOmega@lemy.lol
      link
      fedilink
      arrow-up
      4
      ·
      9 days ago

      Based, too bad it’s not as easy to find jobs to feed the family (me) with better languages usually simply by virtue of them being newer and having less adoption

  • quicken@aussie.zone
    link
    fedilink
    arrow-up
    30
    ·
    10 days ago

    It’s always the AI. We all know they’re pushing the AI button before even reading the rest of the label!

      • VeganPizza69 Ⓥ@lemmy.vg
        link
        fedilink
        English
        arrow-up
        6
        arrow-down
        1
        ·
        9 days ago

        Writing code is bad!

        Writes condensed configurations and properties files in 3 different languages instead. Cloud deployment uses yet another source of configurations and properties.

        Doesn’t write documentation for configuration and properties.

        Ah, yes, that’s much more readable.

        • davel [he/him]@lemmy.mlOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          9 days ago

          Sure, though you’re arguing against an entirely different thing. Nobody said writing code is bad.

    • Swedneck@discuss.tchncs.de
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      10 days ago

      well why is it good? why not just assume the boilerplate as the default and require the user to override it if they want to do something fancy?

      it’s just busywork to always need to write the same stuff, and it also makes the code less readable and many people look at all that boilerplate and nope the fuck out.

      This is why python is so good for getting people to realize that programming isn’t magic, you just write the equivalent of one short sentence and BAM text in the terminal, no need to import the basic ability to print text which is so incredibly inane.

    • Aceticon@lemmy.world
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      10 days ago

      It’s the most boring thing of the technical side of the job especially at the more senior levels because it’s so mindnumbingly simple, uses a significant proportion of development time and is usually what ends up having to be redone if there are small changes in things like input or output interfaces (i.e. adding, removing or changing data fields) which is why it’s probably one of the main elements in making maintaining and updating code already in Production a far less pleasant side of job than the actual creation of the application/system is.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      9 days ago

      Boilerplate is bad because it’s fundamentally just noise. When you read the code you want to be able to tell what the purpose of the code is and what the problem it solves. Ideally, code should be expressing that as clearly as possible. Having a lot of boilerplate is typically an indication that the language semantics don’t allow you to express the solution in a clear way and you have to write a lot of incidental code. The more code you have to read the more cognitive overhead there is in understanding it and keeping it all in your head.

  • taiyang@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    10 days ago

    It’s not really that hard to implement AI as far as I can tell, even if it does produce garbage results. Any CEO that thinks otherwise is getting bamboozled.

    Not that I’m defending AI, boilerplate is still boilerplate and a crappier product is a crappier product. But they’ll take that trade off anyway which is why heads need to roll, lol

  • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    9 days ago

    I find DRY often turns into an antipattern because decoupling is far more important than code reuse in practice. Having a function that supports many different code paths can make it very brittle because any changes to it need to consider all the possible use cases. However, if you have two separate functions that are similar, but can evolve independently then you don’t have that problem. As a rule, it’s better to duplicate code first, and then extract parts that turn out to be general purpose functionality once that’s identified through usage, and to put that code into libraries.