Here's one example (and this is just one example). My workplace makes heavy use of linters and static analyzers. The CI is configured so that if the linter outputs any errors or warnings, the pipelines fail. Often that occurs because an empty code block or type definition contains a space, and the linter really wants to see '{}' instead of '{ }'. I simply cannot imagine the consequences to humanity at large if this excess whitespace ever made it to production. The kicker here is that the default VS Code autofmt wants that singular space to be there, and inserts them itself, and the default Angular linter thinks they really do not belong. I'm not sure which of these two organizations (Microsoft and Google) are right, as both normally emit good practice the way Moses emits commandments, and they are now in direct contradiction with one another.

I have approached colleagues about the idea of maybe turning off some or all of these rules, and was promptly told that I should have my editor configured to run the linter and apply its fixes whenever I save, and given instructions on how to do so. This is a Good Argument, in that it solves my problem effortlessly, but I just can't resign myself to do it, and still find myself embarrassingly pushing commits to apply linter recommendations after opening merge requests. To put it as simply as I can, I have identified The Problem. Please address it. I do not care if your solution is easy and low impact. It does not solve The Problem, it just sticks a layer of paint over it. It's also not just the failing builds that piss me off, it's also that the linter is garbage and overly opinionated and actively makes our code look worse by (for instance) removing line breaks in lengthy call chains or array literals making them longer than 100 characters. Motherfucker I broke that up for a reason.

As far as dysfunction and cargo cult nonsense goes, I have seen a hundred times worse in my time. This is a complete non-issue. But fuck me, I can't do it. I can't be slippery like that anymore. I just can't tolerate all this fucking process that never touches the fundamental problem of engineering nondiscipline. I can't jump on the latest fads that promise to solve every factoring problem and just make code bases wordier and ten times more opaque. I don't want copilot to be fucking turned on by default. It sucks and will always sucks no matter how many teraflops you throw at the LLM and how strongly you believe that AGI is among us. I just want to choke a bitch. I want to punch some poindexters in the face and break their +1.50 glasses.

Maybe I should quit software development? Should I flip burgers? Become an Agile coach? Go fight for the YPG?

  • 5ublimation
    ·
    edit-2
    8 months ago

    deleted by creator

      • daisy
        ·
        11 months ago

        Programmers spent so long arguing about pointless shit like whether or not to put curly braces on their own line that they’ve created software that decides it for them.

        One of the things I love about Go is that this was settled by the language's creators in the early planning. There is exactly one brace style. The gofmt command, standard with the language itself, reformats code to match this style. And most IDEs automatically run gofmt either when saving or on-the-fly. It's one less stupid pointless argument, with the nice side effect of making it super easy to read someone else's codebase.

        • MarxGuns [comrade/them]
          ·
          11 months ago

          Same for Rust and Zig, at least, probably for other languages. To me, it's a huge requirement for any new languages going forward because of how software devs have historically bikeshedded about syntax formatting and other inane stuff.

          • ennemi [he/him]
            hexagon
            ·
            11 months ago

            there are a lot of good ideas in Go, but sadly also a lot of if err != nil { return nil, err } ideas

              • ennemi [he/him]
                hexagon
                ·
                edit-2
                11 months ago

                I'm sure Go could improve things with some syntactic sugar, say like return mightFail()? behing a shorthand for if infamous return nil, err blocks. but then Go still doesn't have ADTs and therefore will never have anything as good as Option :(

                damn I must be painful to work with

              • daisy
                ·
                11 months ago

                Legitimately, if they could add an equivalent to Rust’s let thingy = mightFail()? syntax, it’d be golden. I love errors as values. But the repetitive verbosity sucks.

                It sucks to write. It's great to read.

    • ennemi [he/him]
      hexagon
      ·
      11 months ago

      translation : things were always a lot bad but now even a little bad makes me go gorilla mode

    • ennemi [he/him]
      hexagon
      ·
      11 months ago

      A linter that just deletes all your code

  • darkmode [comrade/them]
    ·
    11 months ago

    I went to college for CS, internships from 2015-2019, full time from 2019-2023. Never going back. I don’t have the desire to jump through the hoops and study for the FAANG interview, don’t want to beg VC for money for my shitty app idea, don’t want to hang around some finance place and wade as a middle manager until I’m dead.

    It’s the kinda gig where u really gotta have a passion for little stupid things like you’ve mentioned in the OP or else you might start asking questions like where the fuck is all this money that pays my bills actually coming from?

  • YearOfTheCommieDesktop [they/them]
    ·
    11 months ago

    this is such a mood. Certain things just drive me nuts now, its just the principle of it, that I'm too stubborn to let go.

    • ennemi [he/him]
      hexagon
      ·
      11 months ago

      in the 80s or 90s there apparently was this practice of paying developers by "lines of code" which is obviously a fantastically bad idea and frankly I think code coverage is exactly the same sort of square-peg-into-a-round-hole management thinking

        • ennemi [he/him]
          hexagon
          ·
          edit-2
          11 months ago

          I wish I could blame management here, they mostly don't get involved in technical stuff so long as the clients are happy. as far as I can tell this is best-practice culture finding its way into the hands of SWEs who legitimately want to do good work but haven't quite had the time to develop good judgement yet (but are, of course, Senior Developers)

          I'm not even any better than they are. it's just fucking exhausting when every practice is justified by the way it's marketed and there's never any reflexion as to whether the touted benefits actually occur in the real world

  • xXthrowawayXx [none/use name]
    ·
    11 months ago

    yeah get out of software development.

    the public sector jobs that you usually have to know someone or wait for a based lazy person to die to get into are open at a rate that's unprecedented in two lifetimes. maybe take a pay cut and become a worthless functionary?

  • MarxGuns [comrade/them]
    ·
    11 months ago

    Do embedded dev. It's slow moving enough that people are still writing eh quality code in C so if you write good code then they'll love you. You'll have to...uh.. get used to the lack of tools compared to other areas of software development.

  • CyborgMarx [any, any]
    ·
    11 months ago

    The tech mages are talking their sacred magick speak again, yes I too know the secret lore of the cpu blob-no-thoughts

  • makotech222 [he/him]
    ·
    edit-2
    11 months ago

    Yeah code style people are bad teammates. I work primarily on C# projects; code style is reasonably consistent between most devs. If you dive into someone else's code, it may not be the same style as you prefer, but you can always easily understand what is going on and change things that you need.

    I successfully staunched a code linter requirement at my previous job because the team was pretty inconsistent on what we agreed was 'good style' and I just mentioned that things were going fine without any style guide for now and we should just keep things in a grey area instead. People's brains work differently and you should let your devs work the way their brain prefers as much as possible.

  • supermangoman [he/him, they/them]
    ·
    11 months ago

    I hate this with a passion. Linter job failures on my teams' pipelines result in warnings, not failures. What a waste of time.

    It's up to the approvers and mergers if the formatting somewhere is too out of whack.

  • burnt_toast [he/him, they/them]
    ·
    11 months ago

    Just amend your last commit and force push. My team does it all the time for little fixes to code that doesnt require a stand-alone commit.

  • BodyBySisyphus [he/him]
    ·
    11 months ago

    as both normally emit good practice the way Moses emits commandments

    They smashed up the first draft because they saw people conforming to a different standard, then came back with something that made less sense?