I’ve ACCIDENTALLY DELETED a Programming Database!


Worst Hosting – They are cheaters. While you purchase their hosting and upload your files you wont have problem. After 45 days … they will start popoing up problems and creating issues… asking you to look into files code. They wont refund money on prorata basis. Its waste going with them …. I never had issues on godaddy. William, Arizona, mtheory.net


β–Ί Get My BEST-SELLING Book, The Complete Software Developer’s Career Guide For FREE β—„
https://simpleprogrammer.com/yt/career-guide-free
SUBSCRIBE TO THIS CHANNEL: vid.io/xokz
THE TECH ACADEMY – Simple Programmer Sponsor: https://simpleprogrammer.com/techacademy

Buy Simple Programmer SHIRT: https://store.simpleprogrammer.com/

I’ve Accidentally Deleted A Programming Database

Someone sent me this Reddit thread that stated that a junior programmer accidentally deleted an entire programming database.

Do this happen very often? What can we do to prevent this?

Should programmers have access to entire databases?

Watch this video and find out!

If you have a question, email me at john@simpleprogrammer.com

If you liked this video, share, like and, of course, subscribe!

Subscribe To My YouTube Channel: http://bit.ly/1zPTNLT

Visit Simple Programmer Website: http://simpleprogrammer.com/

Connect with me on social media:
Facebook: https://www.facebook.com/SimpleProgrammer
Twitter: https://twitter.com/jsonmez

Other Links:
Sign up for the Simple Programmer Newsletter: http://simpleprogrammer.com/email
Simple Programmer blog: http://simpleprogrammer.com/blog
Learn how to learn anything quickly: http://10stepstolearn.com
Boost your career now: http://devcareerboost.com

John Sonmez

45 Comments
  • Kathleen Sebree
    Posted at 08:56h, 29 June

    100% agree. IMHO you should never follow instructions without at least reading it 2-3 times but with that said the person(s) responsible for setting up the production server and the instructions should have never put that information for everyone to see. And even if there is a case where the developers need access to the production database it should always be limited access.

  • Jan Szachno
    Posted at 08:59h, 29 June

    Hey congrats for 100k! Probably going to hit it in a few days πŸ˜‰

  • Jacob smith
    Posted at 09:33h, 29 June

    Yikes

  • Lorenzo'sTechTips
    Posted at 10:40h, 29 June

    Elithecomputerguy also did a video on this post

  • lyoko the
    Posted at 10:53h, 29 June

    my coworker accidently posted Amazon Private keys to github, and the company lost about 20,000$

  • Aurelian Spodarec
    Posted at 12:32h, 29 June

    I always have a plan A, and it's the only plan I got. Plan B, C, D, E, F,G ,H, J, K, L, M, N, O, P, Q R Z, however, the alphabet goes, I don't know. ABCDEFGHJKLMNOPQRSTVUXWZ?

    But anyway, I look at a plan A, as the life plan.

    What's your clear vision? Build a blog, a brand and yt. Okay, work on that.

    Meanwhile, you get screwed around, here and there.

    You go 2000km away from where you are, it fails, you stay there and find your way to live and add extra stuff to your brand. You screw up there you go and live on the street, you manage to get some money, you go rent a room and recover, and be building the brand all the time. When you're on the street you go to the library. You don't eat for 3 days, but you watch John that didn't eat for 3 days and you realise you don't need to eat for 3days, you read on the internet and you are safe for 20days.

    Your brain still works.

    You build your skill and brand all the time.

    It will get better, as long as you keep at it!

    It works for me! I'm like what, from 6ft 73kg, to 57kg, and getting skinnier, but It's getting better in terms of building the reputation online and doing Work! So even if i go on the street now, summer is good anwyas! But I always keep at it, and it always gets better, eventually it will be more than enough!

    You earn little when you start, compared if you could get a job. Then you earn as much as in the job. THen you can grow your business/name infinte, while the job has a limit on how much you can earn.

    lol a job would be good perhaps, if you can get it lol even the toilet one, but even there, they won't hire you with Math degree, nice! Cleaning shit and they want you to be qualified for it! Perhaps you need to count how many you cleaned πŸ˜€

    It's crazy lol i wonder if they have these applications just for the sake of having them.

    lol once i saw an ad for experience in jQuery, and while jQuery ( a job post..) and they were looking for more years to have experience in, than jQuery existed. Wut lol

  • Daryl Wright
    Posted at 12:34h, 29 June

    Agree completely, keep telling it like it is, Jon!

  • Adam Australia
    Posted at 12:42h, 29 June

    I remember the dizzy sinking feeling of pure terror when I realised I had killed a production database due to over confidence in my own skills.

    Was so so glad that I had been suitably paranoid and diligent and had prepared with multiple backups and a proven restore plan πŸ™‚

  • Tekt0nix
    Posted at 12:59h, 29 June

    Almost impossible to believe. First, they don't have backups of the prod db? Second, the company is primarily at fault. Probably not a place anyone would want to work for, move on.

  • Joeward Abante
    Posted at 13:59h, 29 June

    john, i'm not sure you are getting this. i think you are expecting too much from a junior developer.

  • Maximiliano Rios
    Posted at 14:08h, 29 June

    Running out of ideas, quick, let's make something up!

  • zachary taylor
    Posted at 14:46h, 29 June

    Lol the thumbnail was hilarious

  • firesoul453
    Posted at 15:15h, 29 June

    This was posted on reddit a month ago /u/cscareerthrowaway567. Anyone know what happened to him?

  • Luis Mediavilla
    Posted at 16:50h, 29 June

    If it is accidental probably you won't have any legal problem

  • Anthony Caban
    Posted at 18:38h, 29 June

    "I didn't invent this… I didn't invent the world"

    lol, no..no you didn't. But you can be damn well sure someone's gonna blame you for it.

  • Bits and Bytes and Bullets
    Posted at 21:15h, 29 June

    I'm almost thinking of calling Bullshit here. No backups,..seriously!?!?
    Even as a non-DEV, I can see how stupid that would be. Of course, I've seen a lot of stupid people, so,….

  • Greate Snake
    Posted at 22:35h, 29 June

    1.restore
    2.recover
    3.alter database mount
    4.alter database open.

    recovery manager rocks

  • aaron williams
    Posted at 02:06h, 30 June

    this guy is not to blame. shoddy controls

  • Enrique Sayago
    Posted at 04:29h, 30 June

    no direct access to any DB.. read only is the way to go.

  • John Ny
    Posted at 09:05h, 30 June

    I'm starting in a dev job next week, where I have access to the main database, and I have zero experience with data bases. I'm afraid.

  • Russell Thompson
    Posted at 15:23h, 30 June

    One man shop, restored test DB on wrong server/ Thank goodness for strong recovery plan

  • Harrison Brock
    Posted at 16:00h, 30 June

    Well, the DBA should be fired for not restoring the database too.

  • john anderson
    Posted at 02:26h, 09 July

    if the organization gave him access to PROD. and had no controls to protect their PRODUCTION data from a JD first day on the job. its on the company. people will make mistakes. they give him credentials to do what he did. knock it off….

  • Phil Ledru
    Posted at 16:29h, 09 July

    I think the general feeling on reddit and hacker news is correct, it's ultimately this company's CTO's fault, and a huge one at that. As a CEO I would fire that guy. He's the one who should be sued, although there's probably no way he can repair his mistakes financially so the company is probably doomed (backups weren't working apparently, so that's another one of his screw ups, and when you factor all of it, it paints a pretty bad picture of his work, if you can even call it that).

    As for the employee himself, let's remember IBM CEO's words to a young employee who made a mistake that cost a huge amount of money to IBM: (loose quote from memory) "son we just spent 10 million dollars training you, so of course we're not firing you". It's a matter of culture, owning failure is an approach that builds resilience for a company and trust on a human level. Again, great posts on hacker news and reddit if you want to dig into the topic.

    Now beyond that, beyond any rationalization we can make of this situation, I agree with John that one should own their mistakes (and victories), it reminds me of Grant Cardone in The 10X Rule. He basically says that it is a good mind-set to always, always consider that nothing ever happens to you, everything is because of you, even if rationally, scientifically it doesn't make sense.

    Owning everything that happens in your life will ultimately force you to hedge against everything and anything, prompt you to take control as much as you can in any way, shape or form possible, often beyond what 'normal' people would try to.

    It builds a non-limiting, 'everything is possible' mindset that makes you powerful in seizing control of your life, decisions and actions.

    It's not because of a storm that you went homeless, its because you didn't plan for the worst and didn't even try to buy a second home, or have passive income, or secret savings for unpredictable crisis just like a storm killing your home, or have trust relationships with people who could offer you shelter in worst case scenarios, etc. Ultimately it's on you, not the storm, because shitty weather happens and houses can crumble to pieces and *you know that*, you knew, you just dismissed the risk of it ever happening to you and your family.

    So do you want to be the guy complaining to your homeless family that bad weather is bad and mean to you and you're powerless (victim mentality) or do you want to be the guy who's always got plan B, and C,… up to X.

    It may sound harsh and even delusional, control-freak vision, but that's reality for you, shit may hit the fan and sometimes it will: where will you stand at that point? Because no one owes you shit (but some of that shit sure is coming your way), and some balls can't be dropped. Are you the come-back quarterback, the ultimate coach with a plan, the warrior who hikes 10 miles of a snowy mountain when circumstances call for it, or are you just a victim of unfair events? Because fair or not, it's what you think of it, but it doesn't change the reality of said events. It's what you make of it that matters.

    Better yet, how do you process such events? Stoicism through the mouth of Tony Robbins and countless others tells us that not only our life isn't decided by our circumstances but by our decisions and actions, but that we should love our circumstances no matter what because ultimately they build who we become. We should be grateful for the bad as much as the good because these are only thoughts, and the bad is where we grow, it's an opportunity to rise above. If we can turn a shitty situation into an asset, then truly we're indomitable by whatever comes our way. We become more than resilient or resourceful, we become dangerous.

    Oh I could talk about this for hours because it is both so new and so powerful a mindset in my life, but I guess I'll wrap this up by thanking you John for introducing me to that mindset. I'm a changed man and you played a huge role in my transformation.

    Take care, guys. And be strong, own your life!

  • Beginning Programmer
    Posted at 00:30h, 10 July

    Oh how wrong is this… let's count the ways. Incompetent team. Incompetent managers. They failed to back up properly. They failed to delegate appropriate access. They failed to set up the new guy properly. This kid has nothing to worry about.

  • Microphunktv
    Posted at 09:00h, 16 July

    Ah it's that post… The CTO fucked up big time and was just trying to cover his ass. If you put production credentials in a "guide" to setup an environment for a junior dev on their first day, then you're a moron.
    Access to any prod servers (including DBs) should be a closely guarded secret kept by the CTO and a few key senior devs. Everyone else only get access to the test and/or staging servers.

  • Ouafae Haddouchi
    Posted at 21:49h, 17 July

    This is basically my worst nightmare (that I hope I never fall into lol). I started working with this company three months ago, and I am the second developer. The main developer did not provide a copy DB environment for testing because he doesn't seem to know how(he says he lost the passwords for accessing the DB). So I basically have to work on the Prod DB all the time, which is so fucking scary. I am always on egg shells when doing updates or deletes especially when I am doing mass updates that could affect everything. I know that my company should provide me with copy DB for testing before I actually run scripts on the prod data, but the main developer just doesn't know how. It's such a stupid thing for a company to do to allow devs full access to Prod data.

  • hadron89
    Posted at 07:30h, 19 July

    He's a junior dev. You fully expect a junior dev to screw up somewhere, like all beginners in all disciplines will. As a company, you calculate that risk.

    Doing something as stupid as giving out login info for a production DB… Come on. Not the junior dev's fault AT ALL.

  • Jack Windensky
    Posted at 06:07h, 20 July

    I remember talking to my manager about how to update my code into the right environments for testing. I asked him, so I just update the version on this file right? He's like NO! that's live data. You don't mess with that. I thought to myself THANKS FOR LETTING ME KNOW DURING MY SECOND MONTH ABOUT THIS CRUCIAL CRITICAL THING THAT COULD CAUSE MONSTROUS AND CATASTROPHIC DISASTER TO MYSELF AND THE ENTIRE COMPANY!! No hard feelings though.

    This was when I started a few months ago. So I feel for him. Also when I started they gave me an outdated guide on how to set up all my stuff. I know algorithms and data structures – the only thing school is good for. How to set up my server connections, which scripts to run, how their prod/testing environment is setup, etc. Not a clue. I could have easily made a mistake.

    Also just random a note, the reason I need production access is to debug whenever production bugs creep up. You need to peak to see what happened in that scenario. Another reason is to verify any code that you have deployed is working as intended. Granted is only read access. I would lose sleep if I could access production tables while I'm working on something. I lose sleep already knowing my code is out there handling people's lives! THE PRESSURE!.

    Low key sometimes I wish I worked for subway. You know how soothing it would be if the worst thing I could do is give someone too little avocado on their sandwich. πŸ™‚

  • Sander vd Donk
    Posted at 16:33h, 21 July

    Lowercase 'i' could be due to the fact that he/she is not from a native English country :). Many people are nervous for the first day of their job, lots of them have a lot to take in and some of them even sleep less than they should, so it would be wise to not task them with too complex or ambigue stuff in their first week :).

  • Lunaphase Lasers
    Posted at 19:19h, 21 July

    The CTO needs to understand that there are two types of database ops:
    Those who have nuked a prod DB and those who are about to.
    VERIFY YOUR BACKUPS. ALWAYS.

  • Gavin Coyne
    Posted at 20:04h, 21 July

    Remember kids, don't forget to TEST your backups.

  • morphman86
    Posted at 21:55h, 21 July

    What respectable company relies on backups in 2017? I thought most had moved to redundancy clouds now.

  • Adrian Maunder
    Posted at 01:51h, 22 July

    what type of crappy database doesn't have a backup system?

  • James Barnes
    Posted at 19:30h, 22 July

    Sounds like they need a new CTO…. the brand new dev…..screwed up, which happens….Them not being able to restore the data, is the CTOs fault…..or the fact a brand new dev, even had access to the actual prod data….

  • Guyfromhe
    Posted at 18:01h, 23 July

    There's a reason a airline pilot and a junior developer fresh out of school are paid differently… Also it's basically impossible to know what a bunch of custom tools are doing within the first few hours of starting… You don't know how the document was structured, the fact that it even listed credentials if he was supposed to get them elsewhere makes me suspicious of it. Sure you can place a little blame on the guy for making a mistake but we all do it as you pointed out and I'm pretty sure you weren't fired on the spot when you've made mistakes….

  • Alex Nezhynsky
    Posted at 21:20h, 23 July

    This will teach the company a big lesson lol

  • Djazeiry
    Posted at 21:11h, 24 July

    dude , where did you get that shirt pls ? πŸ˜›

  • Maker Mark
    Posted at 01:02h, 25 July

    the title of this is even stupid

  • bigpodgurc
    Posted at 14:46h, 25 July

    well as far as i could understand he was propbably very Nervous and thats even if you normaly have 100% attention to detail you quickly mess up

  • Simon Pratt
    Posted at 11:33h, 26 July

    Yeah, gotta disagree with you on this one, sorry.

    1. As a brand new hire, a more senior member of the team should have been overseeing him setting up his dev environment and should have caught this mistake before it happened
    2. Generic accounts for production systems should not even exist, let alone have their login details written down in plain text for anyone to access
    3. All production accounts should be configured with a minimum access to function policy. Altering database structure is not functionality any production account will ever need (that level of access belongs strictly to the DBA, and sure as heck the DBAs login details will never be written down and shared with anybody!)
    4. Test environment scripts should be written in a way that setup and teardown of test environments use functionality that the account running them doesn't (and will never) have permission to use in production (such as drop and create)

    I agree that developers need a high level of attention to detail, however junior devs are either OCA to the point of probably not being sociable enough to get the job in the first place, or have not yet honed their skill to determine when attention to detail is critical (or what the potential consequences are for failing to pay attention). Either way, a more senior member of the team should be looking over their shoulder to make sure they are setting up their work environment correctly.

    If the employee was based in a country with workers rights (UK, NZ, Australia, to name a few), they are likely well within their rights to sue the company involved for unfair dismissal (and probably should, if only to recover some of their costs associated with getting the job and to hammer home to the CEO how incompetent their CTO is).

  • John Taylor
    Posted at 21:40h, 26 July

    The chain of blame would be the CTO, then the guy that wrote the document, the guy that checked the document, the guy that ultimately approved the document and then possibly, maybe, the guy that ran the script at the end without at least understanding what it did especially when something like DROP/ALTER DATABASE or some equivalent command is present. Although of course someone would be backing up the database and then checking that backup so that disasters like this could be avoided and everyone can laugh about it down at the 'dog and duck' when the situation has been recovered…. IT 101 fail. πŸ™‚

  • Jonas Munthe FlΓΈnes
    Posted at 04:55h, 09 August

    Heh.. I accidentally did this yesterday when I was gonna drop my local schema (Both tabs open in workbench, yay)….I assumed that this would be something I would have done when I had less experience. But luckily we have scheduled backups and I had backed everything up beforehand. Kinda sub-optimal to have the admin user in the documentation indeed.

  • m nm
    Posted at 11:33h, 03 October

    haha that happened alot and one-time i did that too! that was really scary… my many friends lost their jobs also by doing that :p

  • m nm
    Posted at 11:40h, 03 October

    in acompany i used to work in live data all the time!!.. every time when I was needed to work on data I used to take backup of the whole table!! hehe when i left company i just doubled the size of database :p but I guess company should provide backup plans instead of providing a chance for employees to do a mistake.. sometimes junior developers, even senior developers forget to write condition after where clause in an update or delete query.