1. 47
  1. 34

    The top reply by the developer at GitLab mentioned an interesting quote:

    If an intern can crash your company one their first day, your company has failed.

    1. 24

      Here you go people:

      “Unfortunately apparently those values were actually for the production database (why they are documented in the dev setup guide i have no idea). “

      The junior dev is correct. A guide about setting up a test or local database shouldn’t include data on controlling the real one. There’s also the old principle of access control where someone can’t touch a database directly unless authorized. Also, code or config review before what junior devs do reaches production.

      This is pretty epic failure on that company’s part.

      1. 17

        The CTO should have fired himself for allowing a system to exist whereby a new out-of-uni fresh hire can, on his first day and by a mistake that was enabled by the company’s own documentation, destroy the production DB and then discovering that the backups don’t actually work.

        Although the guy himself is to blame for being somewhat incompetent. It is not really unexpectable (new word) for a programmer to know not to run a potentially destructive script on a DB that he does not know can be safely modified.

        All in all an overpriced lesson for all involved.

        1. 14

          Whoever hires this developer next is probably going to get an employee who will be exceptionally careful about touching production.

          1. 5

            I think there’s a lot of myth and not much fact behind this belief. Yeah, yeah, “I just paid a million dollars training the guy.” And all that. But has anybody ever studied that people who make one colossal mistake are less likely to make a second than somebody else is to make a first?

            1. 1

              I’m sure there has been but it’s not worth looking for unless you have lots of time. The reason is that it will likely fall under key words such as “performance management.” Some phrase or set of words that are so overloaded with bullshit research and articles that poor managers like that the noise will be overwhelming. Very unfortunate as it’s a question worth answering.

            2. 4

              Too true. Either really incompetent in a consistent way or life-changing lesson learned from that mistake.

            3. 2

              A good read. And note in the original thread that there are ~40 devs at this company. That’s way too big for the usual start-up excuses of not getting around to locking down production properly.