• MajorHavoc
          91·
          20 hours ago

          They’re referring to the tendency to reload the dev environment from production a couple times each year, while production is being tweaked daily without any record of changes applied.

          Remember, however bad our own shop is, someone out there puts up with crap that even our own team doesn’t have to put up with.

            • MajorHavoc
              3·
              18 hours ago

              Lol. Yeah. Your point stands.I’m not disagreeing with or trying to correct you. Sorry if my comment came across that way.

              I’m just trying to commiserate that cowboying changes into production is so common that it is some folk’s work reality, even on well run teams - i.e. when their peer’s teams are poorly run.

  • steventhedev@lemmy.world
    12·
    20 hours ago
    When I was a young dev
My senior took me into the city
To push my code to prod
He said "Son, when you promo
Would you be the savior of the broken
The buggy and the OOM'd?"
  • HubertManne@moist.catsweat.com
    12·
    22 hours ago

    last place I worked had an environment refered to as poc/staging. poc. staging. these are supposed to be as far apart as possible in a non prod environment not combined.

  • GissaMittJobb@lemmy.ml
    8·
    21 hours ago

    This is what feature flags are for. You can test in production to your hearts content if you use them!

    • MajorHavoc
      10·
      20 hours ago

      Yeah. Warning - uninvited poetic waxing on feature flags and leadership choices, incoming…

      We all agree we inevitably do some live testing at our customers risk, because no test environment is perfect.

      With feature flags, we’re able to negotiate how many of our customers to test on, at a time.

      But some of us prefer to forgo feature flags and risk our entire customer base on every change. It saves money, at least for a little while.

      I’m not exactly fun at executive leadership meetings, but somehow I keep getting invited to them. Heh.