Hugs going out to the teams at Instructure working to fix this. I've been through a similar Ransomware attack (national news stories, lots of customers dead in the water, etc.), and it's about as bad a situation you can wind up in.
It's going to depend on the type of team and environment you work in. Probably on how senior you are as well.
If your boss asks you for specific documents and expects a quick turnaround, and you regularly take 3 weeks or whatever to produce them, then yeah probably.
If your boss generally leaves you alone to find and solve problems on your own, then probably not.
>Is Azure really this unreliable? There are concrete numbers in this blog. For those who use Azure, does it match your external experience?
IME, yes.
I'm currently working as an SRE supporting a large environment across AWS, Azure, and GCP. In terms of issues or incidents we deal with that are directly caused by cloud provider problems, I'd estimate that 80-90% come from Azure. And we're _really_ not doing anything that complicated in terms of cloud infrastructure; just VMs, load balancers, some blob storage, some k8s clusters.
Stuff on Azure just breaks constantly, and when it does break it's very obvious that Azure:
1. Does not know when they're having problems (it can take weeks/months for Azure to admit they had an outage that impacted us)
2. Does not know why they had problems (RCAs we're given are basically just "something broke")
3. Does not care that they had problems
Everyone I work with who interacts with Azure at all absolutely loathes it.
But doesn’t this experience contradict what OP is saying in a way. If azure is always breaking wouldn’t that imply that changes like “adding smart pointers” are being introduced into the codebase?
I don't think it contradicts the OP. OP says the system is unreliable. Memory leaks that lead to out of memory failures for example. Smart pointers would stabilize things. (Also note that OP says their smart pointers PR was rejected).
That's a generalized statement. Smart pointers can stabilize things, if used wrongly they can cause just as many issues. Sprinkling in smart pointers such that there is now mixed use with smart and raw pointers can cause double frees, and huge maintenance issues. So, creating a single PR to introduce smart pointers in my opinion is not necessarily "stability". He should have created an architecture plan and got upstream and downstream aligned.
Firing someone for an honest mistake is a great way to make all of your employees afraid to push changes out of concern that they'll be next (although to be fair this was a pretty big mistake).
Things like this are usually a systemic failure rather than being 100% attribute to a single person.
There are magnitudes of mistakes. I can drop prod 4 times a day on a project that's being used by 4 old grannies to sync their excel file and get away with it. I can get scolded for 5 minutes of downtime at 6 am.
There is a point of responsibility in here, and it is up to the management to triage the fallout of this "mistake".
>before I went to elite companies, where it is quite normal for people to live-and-breath software, at almost all hours.
Honest question: Do they actually _want_ to live-and-breathe software, or do they work in a highly competitive and highly compensated environment where doing that is implicitly required?
Defintely a mix, though I agree with you that the majority fall under, "they work in a highly competitive and highly compensated environment where doing that is implicitly required."
>It is true IF you live and work in the Bay Area, Seattle, and TLV - which represent the bulk of tech industry employment.
Is that actually true (the bulk of people in the tech industry are working in "big tech" or startups)?
I don't know if there's any hard data around this, but my understanding has been that people working for these types of companies are maybe a single digit percentage of all tech workers (if that).
People working for those companies are certainly the most vocal online, though, which maybe skews perception.
Same here. A local grocery store and several other local businesses got bought out and demolished so Amazon could build a new Fresh store.
I guess Amazon pulled out of the project halfway through, since for the last ~2 years there's been a half-finished building just sitting there completely abandoned in our town center.
This is why you shouldn't waste your money on expensive "consultants" like this guy.
We've had 100% success in reducing Dependabot noise by disabling it in our repos. Why should we pay this guy to configure it for us and still end up with Pull Requests being opened?
