• kamen@lemmy.world
    link
    fedilink
    English
    arrow-up
    12
    ·
    1 day ago

    “Which idiot would do that?”

    * looks at git blame for the section and promptly shuts up *

    • mlg@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      23 hours ago

      Man past me should have done a better job

      //Crappy hack to make this work immediately so management will stop breathing down my neck

      Oh wait nevermind lol

    • baahb@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      3
      ·
      1 day ago

      In each of us, not two, but three. Paraphrasing Superfast matt, “that was done by past baahb, and he’s an idiot, but it matters more to future baahb, and that guy is an asshole.”

    • hdsrob@lemmy.world
      link
      fedilink
      English
      arrow-up
      110
      ·
      2 days ago

      Been writing the same software for 20+ years now, don’t even need git blame to figure out what asshole wrote this shit.

    • NotSteve_@lemmy.ca
      link
      fedilink
      arrow-up
      29
      arrow-down
      1
      ·
      2 days ago

      That exact chain of events happened to me at my last job and I audibly laughed realising it was my own code. To my own credit though, it was a file I had written four years prior which at that point was more than half my whole career in the past

    • dan@upvote.au
      link
      fedilink
      arrow-up
      13
      ·
      2 days ago

      These days I see so much AI slop that my reaction when I see code I hand-wrote myself is “hey, that’s pretty good”.

      My team’s code is great, but we use a lot of shared code written by other teams, with varying levels of quality.

    • JATothrim_v2@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      2 days ago

      I have lately jokingly guessed when I see the particular style and confusion: it’s you isn’t it? And so far I have been right. The particular author’s magic has expired, and I see the same fault replicated everywhere he has been.

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

        One of my coworkers is fond of using ternary expressions instead of “if” blocks. Even ones without an “else”. So I see things like:

        condition ? someVar = "blah" : null;

        or

        condition ? doSomething() : null

        Which should both just use “if” statements. Or my favorite:

        condition ? someVar = "foo" : someVar = "bar"

        which should really be

        someVar = condition ? "foo" : "bar"

        • UUUuuuuuh, I am not a programmer (you’re going to say “thank god”), but…

          I sometimes even chain them. You can put yet another ternary operator in the else and keep going. You know, else-if.
          So anyway, I can get ternary operators spanning 2 - 3 lines.
          Oh, I also often have issues thinking of proper loops, so you’d see a few terribly used goto statements.

          Although I do remove ones that are obvious brain fart.
          For example, quite obvious

          void example(bool true_or_false){
              if(true_or_false){
                  //code if true
              }
              else{
                  //code if false
              }
              //other code
          }
          

          Well, I’ve already had my brain goof up even that once or twice. “How the fuck”, you’re asking?

          void example(bool true_or_false){
              if(true_or_false){
                  goto if_true;
              }
              //code if false
              goto end_false_if;
          if_true:
              //code if true
          end_false_if:
              //other code
          }
          

          The brain-fart if-else.

          • lukstru@piefed.social
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 day ago

            You need another goto end right before the end_false_if:, otherwise the false code will always run

            • I tested it, it works as it is.

              #include <stdio.h>
              #include <stdbool.h>
              
              void main(){
                      bool true_or_false = true;
                      if(true_or_false){
                              goto if_true;
                      }
                      printf("This code runs only if false.\n");
                      goto end_false_if;
              if_true:
                      printf("This code runs only if true.\n");
              end_false_if:
                      printf("This code always runs.\n");
              }
              

              If true, it jumps to if_true, then runs other code. If false, the if gets skipped, if false code gets run, then it skips over if true code.

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

            I haven’t seen him do it lately in any code I’ve reviewed but I do change it whenever I see it if I’m doing work nearby lol

  • Thirsty Hyena@lemmy.world
    link
    fedilink
    English
    arrow-up
    52
    ·
    2 days ago

    As the sole programmer of a certain project, I often leave rant comment on what the previous programmer was thinking.

    • HeHoXa@lemmy.zip
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      24 hours ago

      I like to structure my comments as song parodies and see if anyone notices.

      "Is this a real object, or just an interface?

      This gets caught in a pipeline, no escape from transformations.

      Any way the data goes doesn’t really matter to this service.

      …"

    • ScriptSage@lemmy.zip
      link
      fedilink
      arrow-up
      24
      ·
      1 day ago

      I was complaining to my friends about how bad the programming was on a project I was wrapping up and then they asked, “Isn’t this a personal hobby project?” yes it is.

  • Ensign_Crab@lemmy.world
    link
    fedilink
    English
    arrow-up
    117
    ·
    edit-2
    2 days ago

    especially your own code.

    “This is obvious” I said. “Surely I won’t need to comment this,” I said.

    • Aceticon@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      1 day ago

      Sometimes one does something in a certain way (which would otherwise be a shit way to do it) for very good reasons which are external to the code, be they requirements related, external upstream or downstream systems or due to existing system limitations or deployment environment.

      More than a decade ago, I learned that even if one isn’t at all prone to put comments in the code, you should add comments for such reasons in that quirky code: months or years later that will yield exactly the reaction of this meme when you or somebody else sees that code (whilst you might remember why you did, somebody else will certainly not)

      Maybe even more importantly, it allows other people to actually remove that crap if the reasons behind it don’t apply anymore, which they would otherwise not do because they would be fearful that the hacked-together pile of crap was needed for some reason elsewhere they were not aware of so they could not risk refactor it - most long lived codebases out there are riddled with crap which had pretty good reasons to be there back when it was done but it doesn’t anymore, but which newer people can’t just remove until they’ve gained a full understanding of the whole code base and how it’s wired to the rest (and, even then, there’s a risk that the reason is a requirement and if they just remove that code it breaks something that the users expect).

      Even if you’re the kind of coder that thinks that “the code is self explanatory” (something which, by the way, betrays a lack of experience in the full life-cycle of software that has been in production for years and been worked on by several people) do your future self and others a favor by explaining the choices derived from external reasons (“Why has the auto engineer chosen to put the steering wheel in a British car on the right side?”) that led to code design which is NOT explainable by purely internal or good design or coding reasons.

      (Or at least make it stupidly clear in the appropriate level of tests, which normally is requirements testing or integration testing)

      If you’re really good and working in a proper professional environment (most programmer aren’t), consider tracing things back to the entries in the software requirements document, use cases or even elements of an use case, at least for the “quirky” choices.

      • Feathercrown@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 day ago

        Definitely. I’ve seen this advice summarized as “Comment ‘why’, not ‘how’” and it’s always helpful to come back to weird code and immediately understand these things.

  • WesternInfidels@feddit.online
    link
    fedilink
    English
    arrow-up
    64
    ·
    edit-2
    2 days ago

    I go back and look at my old code and find it clear and beautiful, easy to understand, a pleasure to read. “Ah yes,” I’ll say to myself, “that approach was clever and elegant. Gosh, past me was pretty smart!”

    I like to appreciate it in this manner. Because that way, for a moment at least, I can forget about how it doesn’t actually work.

  • AeronMelon@lemmy.world
    link
    fedilink
    arrow-up
    29
    ·
    2 days ago

    Electrical engineer: “what was that other guy thinking?”

    Software engineer: “What was I thinking?” (It’s code from last night)

    • rumba@lemmy.zip
      link
      fedilink
      English
      arrow-up
      11
      ·
      2 days ago

      We went out for drinks one night after work. Upon stumbling back to the office, I remembered I had forgotten that I signed up to make a tool page to mange some data ingest. It was due first AM. I was three sheets to the wind. Fired up LAMP stack, took the samples and made an ingest function. Wired up a textbox, tested it and went home.

      Next AM, I turned it in, there was a minor bug. No problem, I’ll just find the issue and they’ll be good to go.

      cracked the scripts open…

      I could read it. I could see what a lot of it did. I could NOT figure out what some of it was there for. I spent 30m trying to figure out what I was doing. it was only a couple hundred lines. It wasn’t even a copy/paste job. Eventually I ran out of time and just leaned into phpdump, and breakpoints to find the exact error. One function hit a bonefied php bug that caused the debug to go silent. large swaths of the code were unreachable due to essentially a couple of typos. The only reason it worked as well as it did was because their sample data was as simple as imaginable. I put on some Nine Inch Nails and just remade it in about 30 minutes (10m before it was absolutely needed)

    • zqwzzle@lemmy.ca
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 days ago

      What was I thinking?-after every interruption that could have been an email

  • rumba@lemmy.zip
    link
    fedilink
    English
    arrow-up
    20
    ·
    2 days ago

    I watched a team invent a new language to get around updating some eccentric code.

    They could have sat down and commented it and made their changes

    They could have refactored what was there.

    They could have scrapped it and wrote fresh

    Instead, they designed an entire natural language system so that non-programmers who were writing in XML could just write in English.

    They ended up making so many required keywords as helpers that the non-programmers kept using the old system because the XML was easier for them work with.

    Note: wasn’t my code, wasn’t my dept, when I heard the plan I went to check it out, the old system was functional but like C- work at best. At some point, they wrote a compiler for the new system.

    • applebusch@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      7
      ·
      2 days ago

      inventing a new language is almost never the right solution. there was a guy at my last job who tried to do this pretty much every time he ran into a problem with some shitty legacy software he had to work with. rather than take the time to fix it to do what he needed, he took ten times longer to slap another layer of custom bullshit on top of it. ultimately it came down to him being a really shitty engineer too afraid to change existing code, too lazy to do his due diligence, just clever enough to implement a shitty workaround, but not clever enough to realize how shitty it was. everything he made barely worked, was way overcomplicated, and no one else even wanted to try to learn his arcane bullshit syntax.

      • rumba@lemmy.zip
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 days ago

        We do all look at code, get immediately annoyed that it doesn’t just make sense. most of us at least have the wherewithal to stick with it and work on the engine as it sits :)

      • marcos@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        2 days ago

        In the 80s. If you look at what your examples have in common, you’ll notice you’ve heard it in the 80s.

        Too bad 80s nostalgia is all the hype nowadays, but at least this seems to be passing in other subcultures. I really hope it passes in software development too.

        • lime!@feddit.nu
          link
          fedilink
          arrow-up
          4
          ·
          2 days ago

          only one of the ones i linked is from the 80s. i think you’ll find the majority are from the 50s.

  • lime!@feddit.nu
    link
    fedilink
    arrow-up
    11
    ·
    2 days ago

    i did some fun metaprogramming today. i can practically hear my future self screaming.

  • bedwyr@piefed.ca
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    2 days ago

    Electricians are a rather self-impressed bunch in my experience, like I would rather drink with a couple plumbers than electricians.

    • SirSamuel@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      2 days ago

      Electricians think their way is the only way. Get three electricians together and you’ll get four ways of running the conduit, and a six hour argument. Electricians are constantly upset because “those bastards in HVAC put the ductwork in my way”. There are three types of screw an electrician will run into in the field, which is why the average electrician owns forty-seven screwdrivers.

      Plumbers only need to know three things:

      1. Poop rolls downhill
      2. Payday is Friday
      3. Don’t chew your fingernails

      Oh, and if you want to piss off a pipe fitter, call them a plumber