The Worst First Day of Work, Ever

This poor Redditor had a major screw up on his/her first day. Read:

Today was my first day on the job as a Junior Software Developer and was my first non-internship position after university. Unfortunately i screwed up badly.

I was basically given a document detailing how to setup my local development environment. Which involves run a small script to create my own personal DB instance from some test data. After running the command i was supposed to copy the database url/password/username outputted by the command and configure my dev environment to point to that database. Unfortunately instead of copying the values outputted by the tool, i instead for whatever reason used the values the document had.

Unfortunately apparently those values were actually for the production database (why they are documented in the dev setup guide i have no idea). Then from my understanding that the tests add fake data, and clear existing data between test runs which basically cleared all the data from the production database. Honestly i had no idea what i did and it wasn’t about 30 or so minutes after did someone actually figure out/realize what i did.

So, basically, the new person accidentally destroyed the whole database while following the setup instructions she was given. Who is at fault here?

To keep reading, click here: The Worst First Day of Work, Ever

And share your worst first day of work in the comments!

Related Posts

5 thoughts on “The Worst First Day of Work, Ever

  1. Such work environments promote mistakes to be covered up as quickly and quietly as possible. This causes problems in identification of how to prevent future failures. Moral also suffers in employees are always waiting for their turn. Mistakes keep happening and people feel krappy because of it. Punitive work environments are a detriment to safety and performance.

  2. “So, basically, the new person accidentally destroyed the whole database while following the setup instructions she was given.”

    Actually the new person, by their own admission, did NOT follow the instructions.

    But more to the point, the data system 1) should have been protected so that such a mistake could not occur and 2) should have been backed up (although the article does not state that the data was not backed up).

  3. Everybody is at fault. Some more than others. The employee should certainly have followed instructions, and it bodes ill for a developer who can’t follow written instructions.

    But the credentials for the production server should never, never, *ever* have been put in a training document. Whoever did that shouldn’t be allowed anywhere near training documentation, or production servers.

    (And if there aren’t readily accessible backups, multiple people need to be fired, starting at the top of the database admin team.)

    Sadly, this sort of institutional incompetence is more common that you’d think.

  4. As Goober mentioned the production database credentials should never have been put in a training/setup document. Also it is unlikely that they ever changed the password for that account. Finally, why on god’s green earth did they give the account in the automated setup script drop table permissions on production? For “finding” this kind of security issue I would give the new guy an award and fired the database admin.

Comments are closed.

Are you looking for a new HR job? Or are you trying to hire a new HR person? Either way, hop on over to Evil HR Jobs, and you'll find what you're looking for.