[davbryn1]

"What does this teach us? Well, it teaches me to do more diverse tests when doing destructive operations. It also should probably teach something to Vimeo and to my contractor but I doubt it will (and yes, the upload for some reason is still manual to this day. Go figure!)"

So you wrote bad code, didn't test it properly, ran it on production on the Friday before a release and are blaming Vimeo and [name redacted]?

And your resolution was yet another cobbled together script that you probably didn't test?

This isn't a great article to have attached your name to

[chopin]

I'd hire this guy if only being for this frank about his mistake. He owned it and that is what I would look for.

After deletion, what should he have done? Postpone the go-live? That's often not a a cost-effective option. As for a risk-analysis the worst what could happen was deletion of the remaining videos. I don't think that that makes big difference in this situation. And to do the right thing, you have to have the infrastructure in place, if you are in a hurry. I doubt that's the case for a 10 heads shop.

[malexbone]

Agree 100%. Acknowledged mistake, moved forward to find a solution. Reflected on lessons learned. Shared valuable lesson.

To me this indicates intelligence, competence, integrity, grit and generosity. TechnicL proficiency is much easier to come by than integrity, grit and generosity. I would trust the author to deliver on commitments.

[GordonS]

Aye, this is how you learn and make sure it doesn't happen again.

I did a similar thing ~20 years ago when I first started my career, accidentally deleting a production database because I thought I was working on the test database.

I owned it, learned lessons from it, and it's never happened again.

[davbryn1]

Owning the mistake would be fine if he did that - he did'nt. He blamed the company he was contracting for. That's a big no from me

[esquivalience]

It's as if we read different articles. He literally writes that he made "A series of mistakes that could've probably been easily prevented."

[thevinter]

I'm sorry if it came off like that. The mistake in this case was completely mine (bad code and bad testing). The detour on the other two companies was mostly because this way of deleting/recovering stuff should've probably been avoided in the first place, other than that I'm absolutely not blaming anyone else!

[davbryn1]

Don't worry about all that - there isn't a developer worth their salt that hasn't made a mistake. But I'd consider having this blog post and HN post retracted purely for future internet checks. It isn't a reflection on you, and your honesty is fantastic. But there is a lot to be said about using a pseudonym when it comes this close to your employers

[desarun]

I'd probably make your github profile private for a while as well. Or at least removing your real name from it.

[honksillet]

Agreed. But I’d also fire him from this job.

[yohannparis]

Doesn't make sense. Their employer literally paid them to learn from their mistake.

Now, you think they should be fired? So that another employer rips the benefits of that learning experience.

[SparkyMcUnicorn]

"Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?"

-- Thomas J. Watson

[Beltiras]

For having got into a sticky situation and out of it?

[kwertyoowiyop]

Will every developer who has never checked in bad code on Friday, or accidentally deleted the wrong data, please raise their hand?

‘Judgment comes from experience, and experience comes from poor judgment.’

:-)

[gala8y]

Not to mention that he _deleted_, but not _lost_ videos. Nothing to see here.

[breakfastduck]

Vimeo completed a major migration of videos between accounts with no confirmation or communication before commiting it, then refused to reverse the change. Hardly the best service.

The article hardly comes across as 'blaming' them for the core issue but they were definitely not helpful.

[jasonlotito]

> This isn't a great article to have attached your name to

A million times better than your comment.

[davbryn1]

All I did was give advice. If you don't like it it's fine.

[oneepic]

Earlier in the article, the author does call out that it's bad code, so he's not entirely blaming these companies. Anyway: You should not be afraid of thinking about what each party could have done better. Not just yourself, but other people too. When I look back on times where I only blamed myself for prod issues, it was less of a learning experience, and more focused on beating myself up for no good reason. That approach shows that I'm afraid of the consequences, and it's an effective way to feel isolated from the team instead of improving.

[nickkell]

Better to do it before the release then afterwards. I'm assuming this way nobody noticed the issue.

Also, would you rather everyone only ever posted about all the times they were successful?

[dang]

(Since the OP redacted the company name from the post, I've done the same in your comment here. I hope that's ok.)

(We do this sort of thing to protect users, usually as the result of an emailed request, and you can tell when we've done it because of the word 'redacted' in square brackets.)

[smokey_circles]

Oof, we wouldn't work well together. Very rarely is someone good enough to be this obnoxious.

[davbryn1]

I very much doubt you would ever work with or for me.