• @[email protected]
      link
      fedilink
      165 months ago

      You only hurt yourself down the line. My last job had not improved their own product, processes, tools or frameworks, so everything was still stuck in the 90s. Their product was build on an discontinued an proprietary database and server system you never heard about, jQuery UI from 10 years ago and other BS.

      However if you don’t upskill yourself in this situation you will be unemployable in the future, because all other employers demand modern technologies, git, docker, unit testing etc., which I was yelled at in meetings for suggesting it.

      • @[email protected]
        link
        fedilink
        245 months ago

        git is considered modern?

        I don’t mean to bash git but I’d have assumed git is utilized in some capacity in every dev environment.

        • @[email protected]
          link
          fedilink
          14
          edit-2
          5 months ago

          The Lead Dev/team Lead was quite arrogant and in his own mind the worlds best developer who had all the answers. If some technology or software was not written by him or already existed in the 90s it was “useless” and not fit for the company (without him having looked at it or the docs). If asked why we would not use X which was out for years, well maintained, had no critical bugs would solve problem Z we where having, he would reply “because i said so” and insist in writing out own variant - which ended up having 10% of the features, 10 times the bugs, terrible UI and would take months to develop.

          When support repeatetly told him that users had issues with feature X because the only error message on a 10 fields forms page was “Error”, he would respond that this is a user problem, the end user is clearly stupid (despide used in a field where you need to study for years) and that support must hold training sessions so the users can “learn” how to use his product.

          As such, the company would reject git and instead email each other files and changes.

          Each meeting felt like living inside a Dilbert cartoon.

        • Rob
          link
          fedilink
          English
          105 months ago

          There are other version control systems out there, and have been for decades. So yes, I would consider git to be modern.

          • @[email protected]
            link
            fedilink
            English
            85 months ago

            It’s more modern than Visual Source Safe, that’s for sure. I kind of miss the days of coworkers leaving for two-week vacations and forgetting to check their shit in first. It was a built-in excuse for the rest of us to not do anything and blame it all on vacation boy.

        • @[email protected]
          link
          fedilink
          45 months ago

          Git wasn’t used all that much in the 2000s. As far as I know it became popular in the 2010s (though it was always a thing in some circles I think) and then just supplanted almost everything else.

          Also keep in mind some shops tend to follow larger tech companies (microsoft, etc.) and their product offering. So even new products might not have been on git until MS went in that direction.

              • oce 🐆
                link
                fedilink
                25 months ago

                For sure, I wanted to remind the date because it makes it obvious that it couldn’t be much used in the 2000’, even its second half is too short.

      • embix
        link
        fedilink
        75 months ago

        all other employers demand modern technologies

        There are a lot of employers that’ll throw good money at you for maintaining and extending their outdated crap. Have you ever considered learning COBOL?

        • @[email protected]
          link
          fedilink
          11
          edit-2
          5 months ago

          No wonder COBOL programmers are paid a lot, because what would be a 1-liner for “hello world” in other languages looks like this in Cobol:

          IDENTIFICATION DIVISION.
          PROGRAM-ID. IDSAMPLE.
          ENVIRONMENT DIVISION.
          PROCEDURE DIVISION.
              DISPLAY 'HELLO WORLD'.
              STOP RUN.
          

          This is already $6000 worth of code right there!

            • @[email protected]
              link
              fedilink
              English
              6
              edit-2
              5 months ago

              The thing people always overlook is that these legacy systems are only still running because they’re super important. Nobody’s hiring a junior COBOL dev to maintain NORAD, and hopefully nobody’s contemplating putting ChatGPT in charge either.

              The move if you want this kind of job is to learn a language that’s not quite a dinosaur yet, and have 20 years experience in 20 years. Perl or PHP maybe.

  • @[email protected]
    link
    fedilink
    English
    605 months ago

    After so many years in this company, lots of the unmaintainable code I have to deal with is either my own fault, or the fault of someone I used to work with but and now they left and I’m the one who has to apologize for their code.

    If I move to a different company, 100% of the unmaintainable code I’ll have to deal with there will be someone else’s fault.

    • @[email protected]
      link
      fedilink
      205 months ago

      And managers don’t like it when you explain that the code is a unmanageable mess because they put a deadline on every goddamn thing and never pay off technical debt.

      At a new place you can honestly say “the code is kinda a mess, it needs a bunch of work” and the manager can just assume it was because the last guy didn’t know what he was doing and not because of their own shitty management.

      • @[email protected]
        link
        fedilink
        85 months ago

        To be honest, sometimes shit code is 100% the Devs fault. I’ve witnessed it happen with other teams in my own company.

        Let’s just say it was unavoidable to report it

        • @[email protected]
          link
          fedilink
          45 months ago

          Management could implement a code review process to avoid this.

          Software development isn’t a brand new field anymore. Most problems are well known and therefore have well known solutions. So it pretty much always comes down to management not wanting to implement the known solutions to the problems because its easier to blame the devs.

          • @[email protected]
            link
            fedilink
            1
            edit-2
            5 months ago

            They did, that’s why I said “team” in my response, however I will elaborate for you.

            two Devs must review and one dev lead has admin rights to push to protected branches. Problem is when the whole team is not meeting expectations and they all jerk off eachothers bad code.

            My team reviews internally just like they did, the issue isn’t the review process. At a professional level you should trust your peers therefore the issue was the hiring and/or training process

  • @[email protected]
    link
    fedilink
    595 months ago

    Sometimes a fresh pair of eyes on a code base can reveal some opportunities for big improvements in maintainability 😜

    • @MajorHavoc
      link
      375 months ago

      Ahahhahhahha. Ha…ha. Ahem.

      Sorry. The idea that any of the opportunities for improvement at my last “job A” code base might need “revealed” struck me as really funny.

    • gregorum
      link
      fedilink
      English
      25
      edit-2
      5 months ago

      Sometimes it takes a new dev coming in for management to give the greenlight for a major overhaul. It’s shitty, but it’s true.

    • @[email protected]
      link
      fedilink
      95 months ago

      Also new people are still motivated to change stuff. They are not yet worn down by bureaucracy.

    • @[email protected]
      link
      fedilink
      65 months ago

      Opportunity is my managers favorite word. I even got him an ink stamp that said “certified opportunity”

  • @[email protected]
    link
    fedilink
    465 months ago

    Recently switched jobs from maintaining a 15 year old Windows Forms .NET Framework legacy codebase.

    At the new job we stick to Clean Architecture, use unit and integration tests, have a code generation tool, actually make nice use of generics and use dependency injection. Also agile processes, automatic build tools, whatever. The difference is night and day and I’m so glad my ex boss fired me because I told him he’s an asshole and his codebase is shit.

    • @[email protected]
      link
      fedilink
      English
      125 months ago

      My first job out of college I have been able to see a steady improvement in the codebase. A little while ago I had to go back to an old tag and was horrified with what it used to be and impressed how much it improved.

  • corytheboyd
    link
    fedilink
    35
    edit-2
    5 months ago

    You have to listen to your heart, at least once in your career, to learn that grass on the other side is covered in just as much dog shit as it is over here.

    • @[email protected]
      link
      fedilink
      385 months ago

      “Maybe the grass is greener on the other side because you’re not over there fucking it up.”

      -Abraham Lincoln

    • @[email protected]
      link
      fedilink
      12
      edit-2
      5 months ago

      I’ve known people who do this several times in a year. One even came back to his old job, just to leave it within months to go to a new one, brag about how much better it is. He moved on from that job too within a year.

      Might just be the entire industry has reached enshittification in more than one way.

      • corytheboyd
        link
        fedilink
        11
        edit-2
        5 months ago

        To me, a corporation cannot maintain quality code because requirements are ill defined, and there is no “done” state. With those two conditions present, unable to be changed, it’s not possible to form a coherent codebase. Those who try will make things worse, because their abstractions won’t fit in a year or two.

        This is exactly the “messy code” people then leave behind. Bad code can come about for other reasons too, of course, but this is one of the more annoying reasons, because someone wrote it with self-righteousness, as if they were the only people to truly SEE the problem. Sigh.

        It’s fine, this is how enterprise works. You can learn to navigate and make a living from it. You MUST internalize and accept that it is NOT the same as maintaining code for an open source library or whatever people think it’s going to be.

        • @[email protected]
          link
          fedilink
          45 months ago

          because someone wrote it with self-righteousness

          Usually a call sign of someone who hasn’t been really entrenched with bad code to understand their foolishness in comparison.

          I’ve only seen people hold that idea if :

          1. New and amateurish, I give them a chance cuz they might learn. But let them learn.
          2. Someone who’s only ever worked in maybe two places for very long lengths of time, given way too much power too early, people threw around ‘genius’ too eagerly and these people guard their code like a watch dog likely because it’s so fragile a simple ‘()’ in a string will bust everything . No one else can work on it and the only way you can fix it is the moment they leave. They will not learn. You can only hope the eye of Sauron will stop looking in your direction.
  • embix
    link
    fedilink
    305 months ago

    Just rewrite it with 80% functionality and force migrations on the users. Once the remaining 20% “edge cases” that require serious effort hop to the next job - where you where hired to “maintain” such a system and “just add a small feature here and there”. Ooops.

  • @[email protected]
    link
    fedilink
    English
    255 months ago

    Project A: Has 6 different implementations of the same complex business logic.

    Project B: Has one implementation of the complex business logic… But it’s ALL in one function with 17 arguments and 1288 lines of code.

    “The toast always lands the buttered side down.”

    • @[email protected]
      link
      fedilink
      75 months ago

      Only 1288 lines? Can I raise you a 6000+ lines stored procedure that calls to multiple different sql functions that each implements a slightly different variation of the same logic?

      • @[email protected]
        link
        fedilink
        English
        35 months ago

        Actually, I bet you could implement that in less. You should be able to legibly get several weights in one line.

        • @[email protected]
          link
          fedilink
          15 months ago

          You have my interest! (Mainly because I don’t know the first thing about implementing neutral networks)

          • @[email protected]
            link
            fedilink
            English
            2
            edit-2
            5 months ago

            At the simplest, it takes in a vector of floating-point numbers, multiplies them with other similar vectors (the “weights”), sums each one, applies a RELU* the the result, and then uses those values as a vector for another layer with it’s own weights (or gives output). The magic is in the weights.

            This operation is a simple matrix-by-vector product followed by pairwise RELU, if you know what that means.

            In Haskell, something like:

            layer layerInput layerWeights = map relu $ map sum $ map (zipWith (*) layerInput) layerWeights

            foldl layer modelInput modelWeights

            Where modelWeights is [[[Float]]], and so layer has type [Float] -> [[Float]] -> [Float].

            * RELU: if i>0 then i else 0. It could also be another nonlinear function, but RELU is obviously fast and works about as well as anything else. There’s interesting theoretical work on certain really weird functions, though.


            Less simple, it might have a set pattern of zero weights which can be ignored, allowing fast implementation with a bunch of smaller vectors, or have pairwise multiplication steps, like in the Transformer. Aaand that’s about it, all the rest is stuff that was figured out by trail and error like encoding, and the math behind how to train the weights. Now you know.

            Assuming you use hex values for 32-bit weights, you could write a line with 4 no problem:

            wgt35 = [0x1234FCAB, 0x1234FCAB, 0x1234FCAB, 0x1234FCAB];

            And, you can sometimes get away with half-precision floats.

            • @[email protected]
              link
              fedilink
              15 months ago

              That’s cool, though honestly I haven’t fully understood, but that’s probably because I don’t know Haskell, that line looked like complete gibberish to me lol. At least I think I got the gist of things on a high level, I’m always curious to understand but never dare to dive deep (holds self from making deep learning joke). Much appriciated btw!

              • @[email protected]
                link
                fedilink
                English
                25 months ago

                Yeah, maybe somebody can translate for you. I considered using something else, but it was already long and I didn’t feel like writing out multiple loops.

                No worries. It’s neat how much such a comparatively simple concept can do, with enough data to work from. Circa-2010 I thought it would never work, lol.

  • @[email protected]
    link
    fedilink
    215 months ago

    Learning to deal with “unmaintanable” codebases is a pretty good skill. It taught me good documentation and refactoring manners. It’s only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.

    Code should scream it’s intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don’t). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today’s version). Tests are documentation. Often the only up to date one?

    • corytheboyd
      link
      fedilink
      115 months ago

      This right here. Get good at navigating code of questionable quality that you didn’t write. If you can’t do it, start questioning your tools, and mastery of those tools. For the big boy jobs, you should be working with existing code much more than writing new code. Learn to get excited by tweaking existing systems with a few well placed, well researched changes, instead of being The Asshole that adds a new abstraction wart.

    • @[email protected]
      link
      fedilink
      45 months ago

      I’ve known influential assholes who poopood commentating as if it’s only a superficial job.

      I hate those people.

  • magic_lobster_party
    link
    fedilink
    9
    edit-2
    5 months ago

    I left a company when management decided to discontinue a product right after we finally made its code more maintainable.

    Had a look at the product that would replace it, and it was a bigger mess from what we started with.

  • @[email protected]
    link
    fedilink
    4
    edit-2
    5 months ago

    I see it as a win, I love refactoring bad code . Just feels so nice afterwards.

    Especially when you can remove thousands of lines of duplicated ui code.

    That’s so much better than writing new code