A couple of things:
* It's mostly hobbyists running their instances, some literally in their basement.
* Most scaling glitches have usually been addressed within a few days. The comparison to early-day Twitter is fair, maybe people have literally not expected such a fast scaling route.
* I don't think anyone in their wildest fever-dreams expected Elon Musk to burn down Twitter this fast, thus causing a mass-migration.
The UK royal family has pretty wide control over what can and cannot be said about them in the media.
There is for instance, many stories about royal improprieties that have been covered up in recent years, in exchange for “juicy” Harry & Meghan stories being circulated in their place. This is probably at the core of the schism within the royal family. I can read about it, because I’m not in the UK. Bet it’s not very well covered in the UK though.
But outside web-browsers, I'm not sure it is anything anyone wants - like you imply, in China it's probably handy, because it is a reliable route into all the services that are blessed by the CCP, which means you avoid running into firewalls & thought police.
Not sure he lied. I think he fooled himself into thinking that moderating a social media platform can be done on a rose-tinted ideological basis. Then reality hit, and the fact is, there are so many edge-cases that being ideologically consistent is almost impossible.
Moderation is hard. And it matters, both to keep audiences & advertisers. Besides, First Amendment-based moderation is not even possible for an international company. Most of Europe have strict laws on holocaust-denial. Thailand & the UK have laws banning speech offensive to their royal families.
Not sure it’s long term the most valuable thing I built, but definitely short-term most profitable:
Built an airline pricing system as the sole developer in 3 months in the early 2000’s.
When demoed during late stages of development, it received pre-order guaranteed sales from airlines of $60mn for the next 12 months.
I was paid a paltry $500/day for the contract, and got my marching orders when it was done.
I'm wondering if this erratic behaviour is Musk having some sort of breakdown over how things are unravelling?
* Currently that revenue is cratering and things are not going well. Bankrupcy is a real risk with the high debt servicing cost for the take-over.
* If the value is going quickly in the direction of $0, banks will call the loans.
* If banks call the loans, he has to sell Tesla stock to pay the $44bn.
* If Musk starts to sell Tesla stock at that scale, the value of Tesla could quickly crater in the current climate. It's the last bubble-stock of this cycle, still 80% way to go down, if valued like its auto industry peers.
The outcome of that could be that even selling his entire holding of Tesla, Musk could end up broke, and potentially still owe money from the Twitter take-over.
It would make the wealth destruction of FTX look like a Sunday stroll in the park.
Honestly, I think any "smart money" managers who invested in this should be ashamed. It's absolutely an indictment of their intelligence.
The basics of due diligence is:
* How is their record keeping of board decisions & financials?
* What board decisions and indemnities exist in those records that may have conflicts of interest or claims from other third parties? (FTX didn't even have a board)
* etc..
Furthermore, probably should raise every red flag ever for a reasonably intelligent person if some 20-somethings with a few years of experience claim they have the secret sauce to trade successfully under every possible market regime. It falls on its own implausibility and only reeks of hubris.
To understand most market regimes likely to occur, you likely need people in their late 50'ies onboard, or even older (there's a reason Buffett, Soros et al come out relatively unscathed out of most crises, while everyone else bleeds out).
AWS, GCP et al have already commoditized DB management. These are pretty well-defined steps, there are no good reason why they should require you to pay someone $200k specifically for those.
I think the natural evolution is that both smaller cloud providers AND open source catches up, providing either managed services that are equivalent, or software that effectively makes your DB and other services feel like a managed service.
Depends:
If you work remotely, using VS Code Liveshare or IntelliJ CodeTogether (depending on tooling) works a charm.
In office environments, I once worked in a place where each workstation had two sets of mice and keyboards connected.
Main thing about pairing is communication: one person "drives", while both people talk through what they are doing/thinking. The non-typing partner can be a "map reader" of sorts, thinking ahead. It really will be different from person to person.
The benefit of remote setups with two people working the same code in their own editor is one person can run ahead and write the tests, while the other writes the implementation code (and both communicate what they're doing).
What either setup has had in my experience is constant communication between the parties.
Firstly, you got your _first_ swe job in August. Companies that hire juniors for first jobs shouldn't expect to have fully formed contributors from the gate. It's probably a year or two before you should be expected to be a reliable contributor.
I know with todays inflation in "senior" titles, it comes earlier, but personally, I have low trust in anyone who hasn't done the job for 10+ years.
As more concrete advice:
Own the fact that you are green & new. Ask the "dumb" questions. If you are unsure on how to start something, ask "what would be a sensible, concrete first outcome on the way?". Ask, ask, ask.
Also, as a junior, it is immensely valuable to pair on problems and code with more senior members. So if it's not a thing, maybe suggest if you could try pair programming from time to time in the team. It reduces bugs and errors even for very senior people.
Finally, mistakes happen. Sure, try to avoid them, but don't freak out when they happen, just find a solution to correct it. Every mistake you make is a mistake you are less likely to make again (but some of them, you will make again, and that's fine).
If you are able to do expensive mistakes on production systems, I'd suggest it's more of a process problem than a people one.
Autoscaling groups solve the problem of ensuring you have the desired number of server nodes running.
They do not in anyway solve optimal placement of jobs. It only works “optimally” if you are running just a single service, or services that can all run fine on a single node, in which case you don’t need a scheduler to begin with. The Autoscaling group in this case only provides you with scaling & redundancy, not scheduling capabilities.