Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don’t let code become stale.

  • @[email protected]
    link
    fedilink
    English
    151 year ago

    Kinda acceptable if you have a slow release cadence. Everything needs to be reviewed and fixed/accepted (with defect/US raised) before production though.

    Needs to be in a smaller team with decent Devs too though!

  • DefinitelyNotAPhone [he/him]
    link
    fedilink
    English
    161 year ago

    Nothing improves morale like the on-call having to unfuck production for the third time that hour because mUh VeLoCiTy decided code review and testing in CI was too slow.

    Techbros are fucking cultists.

  • @[email protected]
    link
    fedilink
    941 year ago

    Having to go through the process of merging hurts morale and slows performance. Give everyone on your team the right to force push to master.

      • MeanEYE
        link
        fedilink
        21 year ago

        I honestly wouldn’t see this as a problem. But if you break something it’s up to you to fix it. But we also don’t do CI. We release features in batches after they have been tested and seen to be working.

          • @[email protected]
            link
            fedilink
            61 year ago

            New employees are responsible of at least 75℅ of documentation clarification and process overhaul.

            • @[email protected]
              link
              fedilink
              41 year ago

              I’m totally on board with process overhaul. Ours was stupid when I started, I said it was stupid, and nothing changed. If someone else comes in and can say it’s stupid more convincingly than me, that’s great.

  • buh [she/her]
    link
    fedilink
    English
    101 year ago

    What if instead of continuous integration we had continuous Disintegration, where you code while listening to The Cure on repeat

  • @[email protected]
    link
    fedilink
    221 year ago

    This is satire, right? Surely no one would put their name on that publicly?

    Like someone working in a kitchen boasting about a life hack of not wasting time with hygiene.

  • @[email protected]
    link
    fedilink
    28
    edit-2
    1 year ago

    What does “stale code” even mean in this context?

    Does that mean it falls behind stable? Just merge stable into your branch; problem solved.

    Or is this just some coded language for “people aren’t adopting my ideas fast enough”. Stop bitching and get good.

  • @[email protected]
    link
    fedilink
    English
    1881 year ago

    Having a hard time determining whether this is sarcasm or not. Then I see the phrase “JavaScript Engineer” and become doubly confused.

      • @[email protected]
        link
        fedilink
        61 year ago

        That could still be trolling. But LinkedIn is so full of utter garbage like this that it’s believable

        • @[email protected]
          link
          fedilink
          21 year ago

          I don’t think so. I just made a screenshot of one random convo he’s having about this, but there’s loads more in a similar fashion.

          And all of his other posts besides this one seem legit on the surface.

          So it would be pretty weird if he randomly has a very bad take, and then just claims “Lol this was a troll post, gotcha!”… That’s pretty much the 4chan defense when you get called out - “Haha guys, I’m actually not r-worded, I’m just trolling!”

      • @[email protected]
        link
        fedilink
        English
        28
        edit-2
        1 year ago

        I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage.

        – Kurt von Hammerstein

        LinkedIn is Facebook for that last type.

      • @[email protected]
        link
        fedilink
        61 year ago

        Wow, of course he’s pretending the response is a misrepresentation of his opinion instead of defending it in good faith.

      • Aviandelight
        link
        fedilink
        121 year ago

        That’s a relief because I thought I’d stumbled into LinkedIn Lunatics for a hot second.

        • terrrmus
          link
          fedilink
          English
          181 year ago

          Linkedin is for lunatics. Just a bunch of goobers giving digital handjobs to each other.

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

    That’s nice but it goes against our quality standards and the international quality standards we are charging the client extra for adhering to, the line you’re trying to merge into is stability and needs CCB approval for the merge, and the client has specifically requested only showstopper-level bugs be addressed for stability lines. You know what, I have neither the time nor the crayons to properly explain this to you, a consultant that supposedly knows the business. Pack your shit, you’re gonna have a wonderful time posting this crap on LinkedIn instead. #gitshiton

    2 days before, at Pete Hurrd former job

  • MeanEYE
    link
    fedilink
    91 year ago

    Am not sure I disagree but I don’t agree completely. It’s insane to merge things that go to production without testing. However at the same time I don’t like continuous integration one bit. Open source mantra is great in my opinion. Release early, release often. If code chews some important data, have a test version of it that needs to run some time before it gets pushed to production.

    Delaying merge of someone’s code means branches get further and further apart. At the same time code in main branch gets fixed and tested the most. I would merge often but only full features. None of the half-done stuff. Let humans test it a bit before it reaches target audience. That is usually good enough to catch most bugs. Those that do happen to leak into production are easily fixed since you have fast development cycle and deployment pipeline. And backup frequently.