Junior Dev destroys PROD DB on first day.
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
@Kelly said in Junior Dev destroys PROD DB on first day.:
The levels of organizational failure there are incredible.
It almost goes beyond failures to simply issue credentials with access and soars right into professional malpractice on the CTO's part.
Not really. CTO is an engineer, no production tie in. Why does the CTO have that access is more of a question. That department should not have production access.
-
@dafyre said in Junior Dev destroys PROD DB on first day.:
That's rough though. Why would they have a junior dev with full control credentials on a production database on day one anyhow?
It's because the creds were public and put into a doc that EVERYONE has. Zero security.
-
@momurda said in Junior Dev destroys PROD DB on first day.:
Yes, whoever made those instructions with admin db user creds on them, that is who should be fired. Probably the CTO who fired the kid.
CTO should face legal action. Firing someone as a cover up is a big no no. Someone higher up, like the board, should step in and look at what's going on there.
-
And look... no backups. And they have the developers trying to do the restores. Apparently they thought that they could get away without an IT team?
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
@dafyre said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@dafyre said in Junior Dev destroys PROD DB on first day.:
That's rough though. Why would they have a junior dev with full control credentials on a production database on day one anyhow?
Only a couple people should have full read/write access to a PROD DB. A first day Junior should only have Read Only. He only needs write access to his sandbox.
Agreed!
I used to have a user (CFO) that was half ass proficient in MS Access. All day she would have her Access & Excel forms up that created a RW connection to the main DB so she could run queries against the data. Told her many times how dangerous it was to do that but she insisted and being over the IT dept. we didn't have a choice. Well one day she messed up and committed a change to a table and managed to break it. Luckily we had live backups of the data and nothing was lost.
In the end she still insisted on doing it her way and even though she messed up she wasn't going to change her ways.
Was the CEO aware?
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
@dafyre said in Junior Dev destroys PROD DB on first day.:
That's rough though. Why would they have a junior dev with full control credentials on a production database on day one anyhow?
Only a couple people should have full read/write access to a PROD DB. A first day Junior should only have Read Only. He only needs write access to his sandbox.
All developers, even the CTO, should be read only at best. PEOPLE don't need RW access to databases at all. Developers should be working on development, not production. There are cases when devs need to see production, but that's really, really rare.
-
@Kelly said in Junior Dev destroys PROD DB on first day.:
The levels of organizational failure there are incredible.
Hopefully this is public enough that the CEO stepped in and let the CTO go.
-
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Still with that much incompetence going around, and a supervisor who is gonna fire you rather than educate you and/or put the blame where it actually belongs, I think the guy is way better off staying fired and looking for a job at a company.
-
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@Kelly said in Junior Dev destroys PROD DB on first day.:
The levels of organizational failure there are incredible.
Hopefully this is public enough that the CEO stepped in and let the CTO go.
How is it public?
It is 100% anon.
Unless someone names names and also points the CEO or board to Reddit, this is nothing.
-
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
-
@JaredBusch said in Junior Dev destroys PROD DB on first day.:
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@Kelly said in Junior Dev destroys PROD DB on first day.:
The levels of organizational failure there are incredible.
Hopefully this is public enough that the CEO stepped in and let the CTO go.
How is it public?
It is 100% anon.
Unless someone names names and also points the CEO or board to Reddit, this is nothing.
The incident is public. Hopefully someone from there runs it up the flag pole.
-
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@dafyre said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@dafyre said in Junior Dev destroys PROD DB on first day.:
That's rough though. Why would they have a junior dev with full control credentials on a production database on day one anyhow?
Only a couple people should have full read/write access to a PROD DB. A first day Junior should only have Read Only. He only needs write access to his sandbox.
Agreed!
I used to have a user (CFO) that was half ass proficient in MS Access. All day she would have her Access & Excel forms up that created a RW connection to the main DB so she could run queries against the data. Told her many times how dangerous it was to do that but she insisted and being over the IT dept. we didn't have a choice. Well one day she messed up and committed a change to a table and managed to break it. Luckily we had live backups of the data and nothing was lost.
In the end she still insisted on doing it her way and even though she messed up she wasn't going to change her ways.
Was the CEO aware?
Yes, Didn't care. He said if she deemed it "safe" then it was OK.
-
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
If he wanted to he could sue for his job back I'm sure.
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
If he wanted to he could sue for his job back I'm sure.
Maybe. Many states have labor laws that allow firing during a defined onboarding period for any reason as perfectly legal.
-
@JaredBusch said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
If he wanted to he could sue for his job back I'm sure.
Maybe. Many states have labor laws that allow firing during a defined onboarding period for any reason as perfectly legal.
In most cases it would be a probation period but it would all depend on his contract. Since he moved cross country to take the position I am sure there was a contract.
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
If he wanted to he could sue for his job back I'm sure.
They don't want to work for this company, no one does. If they are going handle such a reasonably understandable mistake in this manner I shudder to think how' they'd handle bigger issues. I mean, he could find himself charged with trespassing if he's 5 min late.
-
@JaredBusch said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
If he wanted to he could sue for his job back I'm sure.
Maybe. Many states have labor laws that allow firing during a defined onboarding period for any reason as perfectly legal.
Even in those states, which are numerous, that never covers bad faith. No matter how much you are allowed to fire someone on the first day things like bad faith and discrimination override those. Nothing ever removes the good faith requirement of the hiring.
-
@Kyle said in Junior Dev destroys PROD DB on first day.:
@JaredBusch said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
@scottalanmiller said in Junior Dev destroys PROD DB on first day.:
@jrc said in Junior Dev destroys PROD DB on first day.:
So the dude followed the instructions a little to closely and was fired due the results of that. F that noise. Not his fault at all.
No backup to restore? Also, not his fault.
Legal action against him, not bloody likely. If anything he has a case against them for wrongful termination.
Wrongful termination to cover up the person that fired you's mistake and then threatening you on top of it? That's a good combination for the HR to hear.
If he wanted to he could sue for his job back I'm sure.
Maybe. Many states have labor laws that allow firing during a defined onboarding period for any reason as perfectly legal.
In most cases it would be a probation period but it would all depend on his contract. Since he moved cross country to take the position I am sure there was a contract.
Even with a contract that said so, I'd say his case for bad faith is really strong.
-
@jrc said in Junior Dev destroys PROD DB on first day.:
@Kyle said in Junior Dev destroys PROD DB on first day.:
If he wanted to he could sue for his job back I'm sure.
They don't want to work for this company, no one does. If they are going handle such a reasonably understandable mistake in this manner I shudder to think how' they'd handle bigger issues. I mean, he could find himself charged with trespassing if he's 5 min late.
Yeah, he's lucky to be out of there. He needs to name and shame, though.
-
Yeah, if he decides not to go back, then he definitely needs to name them somewhere. I am sure local papers would be interested in the story. Though he should make sure that doing so does not expose him to legal action.
