user15672

What on earth were you doing that required solving software problems under extreme pressure?!

This sounds like an incredibly toxic working environment, where developers are either being allowed to create fires on production systems, or management is completely incompetent or both.

Also, being able to "handle it" has nothing to do with anything in this discussion. I'd much prefer to hire someone capable enough to not need to "handle it" than someone proud of the fact that they often s*it the bed but are willing to jump up and do the laundry under pressure.

Yes, yes it is

I'm not sure you've understood what the problem is. They were removing some servers from a group. This isn't something that get's a dry run, not without spinning up the entire AWS infrastructure. It also wouldn't have helped a jot, since the issue came about after an employee executing a playbook made a typo.

There's no way this could have been mitigated with a dry run. They're mitigating it in future by putting more aggressive safeguards in their tooling, which is the correct way to mitigate this sort of issue.

Beyond a typing mistake, it's not really very similar. The Gitlab incident was one avoidable problem after another, ending with a giant WTF when they found out that no-one had even tested the backups were working.

This is a case of someone slipping on the keyboard, removing more capacity than intended and the recovery process taking longer than expected. The process actually seems to be working (to a given value of working), but the amount of downtime was way above acceptable. They've already put more safeguards into the tooling to prevent the situation from happening again.

S3 is also orders of magnitude more complex than Gitlabs infrastructure, so while the amount of time the outage lasted for is not acceptable, it does show that they at least have working processes for critical situations that allow them to get back in service within a day, which is pretty impressive.

Did you really just complain that REST is bad because you couldn't find an auto-generation tool to do your work for you? Because that's hilarious.

Also, you don't seem to have looked terribly hard, because there are a few really powerful tools out there for autogenerating server and client code for REST APIs, as well as mock servers and a whole host of other tooling (See: Swagger, RAML, API Blueprint for starting points).

Again, you've put your own tone on things.

"It also keeps a sense of professionalism as it's clear that no blame is being assigned" is not the same as "you guys acted unprofessionally!". It's letting the GitLab guys know there's a potential problem with the communication style at that point in the story.

I find it funny that in a comments section full of comments about allowing a frank learning experience you're being so down on someone giving tips to consider learning from.

Woah there! I think you may have misread the parent as it looks like some friendly advice to me (with actual reasons and stuff), rather than the "You shouldn't have done that! You've destroyed your company!!!!" you seem to have read it as.

Heck, they didn't even say to retract anything from the report, just maybe to leave adding names to things until a later date in future incidents.

This is a pretty terrible attitude, and is a sad explanation of the churn in the JS community. FE does not work like this and I really wish some of the less professional crowd would stop keep spouting this sort of nonsense.

You start with the damn requirements and then look at how the application may need to be built.

The latest browser APIs are not useful for 99% of the FE work going on out there. Yes, I know it's more satisfying to pretend that it is important, but it really isn't. Just because you can hook something up to a users webcam, or post annoying browser notifications about the latest cat picture a user uploaded doesn't mean you need to or even should.

FE is not a special snowflake. It's no different from most software development (and yes, other, non-FE developers have to figure out cross platform issues as well). If you want to be taken seriously in software development, then stop with the unprofessional attitude and learn how to do something useful for your users, like <a href="https://en.wikipedia.org/wiki/Progressive_enhancement">Progr... enhancement</a>.