Software developer screws production database on first day of job, gets fired, may face legal action

First day on job, a junior software developer accidentally destroys company’s entire production database, gets fired and may face legal action

This is one embarrassment that any intern would never want or face in his life. One the very first day of his job after completing an internship, a young junior software developer accidentally destroyed the entire production database of the company he was working in.

Redditor, cscareerthrowaway567 made a thread of the ignominy he suffered on the first day of his job and found empathy among fellow Redditors. cscareerthrowaway567 whom we will call ‘Bob’ joined an unnamed company after completing his internship. All things were going smoothly till he was given a document detailing how to set up his own local development environment for him to code. Which involves run a small script to create my own personal DB instance from some test data. After running the command

The job was simple and involved running a small script to create his own personal database instance from some test data. After running the command he was supposed to copy the database url/password/username outputted by the command and configure his own dev environment to point to that database.

That is when misery struck. Being his first day on the job, Bob enthusiastically set about doing the job assigned. Unfortunately, instead of copying the values outputted by the tool, he used the values mentioned in the document. Unfortunately for him, the document contained values that were actually being used for company production database.

Once Bob used the values from the company document all hell broke loose and the new values cleared all the data from the production database. Bob was shell shocked for next half hour as he saw his first-day virtually destroy the entire company database. After some time, everybody noticed something amiss and the company CTO immediately summoned Bob to fire him.

In Bob’s own words:

While what i had done was sinking in. The CTO told me to leave and never come back. He also informed me that apparently legal would need to get involved due to severity of the data loss. I basically offered and pleaded to let me help in someway to redeem my self and i was told that i “completely fucked everything up”.

While we can all agree that what Bob did was wrong and that too on his first day of the job, the fact that the company document main production values in the dev setup guide to be given to fresher raises doubts about company ethics. To add to his woes, in the ensuing mayhem, Bob absentmindedly took the laptop assigned to him home.

Bob has since been fired and is awaiting legal notice from the company for destroying their database. Fellow Redditors empathized with Bob for the situation he was in. Exactly five years ago, a young post intern employee who got a job at Amazon had done a similar thing on his first day. He too was fired but not before bringing half of world’s internet down.

Other Redditors offered Bob words of comfort citing several similar instances. This may help Bob who is anyhow undergoing tremendous stress of screwing the company database on the first day of his job at the start of a bright career.

Are you with Bob or do you think the company did the right thing in firing him? Do you think Bob should pay to the company for screwing their database? Give you opinions in the comments and we will make sure they reach cscareerthrowaway567.

13 COMMENTS

  1. He had a admin account on first day? LOL
    No backups? LOL

    For us it takes one week to get all shitty approvals to get admin…
    It was junior so senior wont do backups? heh

    How this is possible in 2017 with all these tools around… ROFL 🙂

  2. LOL sure Bob screwed that but they should have backup date right? what kind of tech company doesn’t have a backup server?

    If they did not have a backup server, There are actually third party software that can retrieve the last operation and all the data affected by the operation and revert it.

    if they have backup, they can use that to restore the data.,

    Firing Bob was too hasty and a bad attitude when it comes to the CTO’s Responsibility, leadership and Liability.

  3. If that is all even true, or at least even partly true, then no – firing him is unfair. I believe in support & second chances in the workplace and think that an employee would learn valuable lessons from: 1, his actual error 2, a supportive team environment and 3, being part of the solution to the problem.

    There is also a chain of responsibility involved in the incident as there were actions of others before him that contributed to the outcome. Examining all contributory factors and contributors with a view to collectively preventing such issues in the future would be a far more productive reaction from a CTO. Bad management filters down – responsibility ultimately filters up.

  4. Any company that does not have a backup from the night before on their servers is not a company I would ever want to work for anyway. I know that he screwed the pooch by killing all the data but he should not have been given a document that contained the information to live data and he also should not have access to a database of that nature on his first day anyway unless his primary job was just to work in that database in which case he should have known to check it out beforehand. This was just a fail on a lot of parts but for the company to threaten legal action you can tell that they need to get their stuff together unless, of course, the entire day that was lost amounted to enough to involve legal in which case even if the backups were there he is still screwed.

  5. He should not have been fired. He made a very understandable mistake, following the documented procedure. There are many things wrong in this environment that we’re not his fault.

    1 – a new, junior Dev, should not have access to prod. Read only maybe, but nothing more.

    2 – they should have backups

    3 – the setup doc shouldn’t include prod values

    I think the CTO is responsible, as he is ultimately responsible for the lack of proper security and backup procedures.

  6. Still Sounds weird too me….Meaning delete permission was not restricted on the life server. To me i think its the fault of the company. The company should at least have a backup server.

  7. Seriously, no backup and using values from the production database in the document explaining how to set up his development environment. Talk about a disaster waiting to happen. Who are the people responible for those things? They’re the ones who should be fired. As a former software couse developer and trainer, you never ever use real database values in any documents. And no backup, who is run ing that company, the 3 stooges.

  8. After reading the reddit thread i have to say the following:

    – In general, junior people cannot be legally prosecuted for mistakes, regardless of the gravity of the production data.
    – The junior learned from his mistake, a bit the hard way though, and another company will eventually benefit from it. This will may be a hard-learnt lesson for the company on the development process and how they treat their employees, since mistakes can and will happen anytime. If I were that developer, I wouldn’t even accept a second offer from them. There’s no telling what else could follow.
    – CTO’s attitude is at least unprofessional, by simply shifting the blame and not even caring about the root cause.
    – Why even put production credentials on the dev environment setup manual?
    – Backups?

  9. Bob has made a mistake, but for that mistake to become a catastrophe it needed:
    1) Insufficient separation of system administrator and developer functions.
    2) An apparent lack of back-up.
    3) Readily accessible login details for privileged accounts.
    The company should be audited.

LEAVE A REPLY

Please enter your comment!
Please enter your name here