Giving a "junior dev" access isn't the issue; after all, that dev probably writes code that can execute SQL.

The problem there was not having any safeguards against running arbitrary commands and not being able to just rollback from the transaction logs. Seriously, it should be a small annoying incident. Screwed up some data? OK, stop things, restore, rollback to the transaction before you screwed it. Apologize and move on.

Giving the Jr Dev access wasn't the problem; your site should be Jr Dev proof (i.e. have backups). If that wasn't a problem, then they only have themselves to blame for investing in someone they obviously didn't want.

Besides, just because you're inexperienced doesn't excuse stupid behavior, and I'm struggling to think of how one might accidentally drop a database after logging into a production environment—I would suspect that people were already lax about it if a Jr Dev was doing it.

If I recall correctly, he was developing a new feature, and the only way to test his work was by creating and dropping test tables, on the production db. One day he dropped the wrong thing. I don't think he had any technical or academic background, and there was no oversight.

> the only way to test his work was by creating and dropping test tables, on the production db.

Really? He couldn't restore a backup locally and test against that? You guys couldn't roll back via transaction log? Mistakes ALWAYS happen, and it's just unfortunate that the Jr Dev was the first person to get screwed by one.