API gateways are primarily used for HTTP traffic coming from clients external to your backend services eg. an iOS device (hence the term 'gateway' vs. 'mesh'). I don't think they support thrift or grpc (at least aws doesn't, not sure about other providers).
https://aws.amazon.com/api-gateway/
Counterpoint to the Clarendon vs. DC. IMO Clarendon bars are chock full of college frat bros with next to no diversity, while DC is more of a mixed scene.
As someone who moved from DC proper to NYC, DC is nowhere near NYC in terms of expenses. In 14th St or Logan circle you can get a brand new 2BR for the price of an old tiny, dilapidated 1BR in an equivalent area in NYC. You can likely even get a 3BR older row house for the same price as a 1BR in Manhattan or prime Brooklyn.
Not to mention, in NYC it's very difficult to buy a home as they are ~30-40% more expensive than renting, with high maintenance fees. For example, a 2BR in Upper East or West side (not near central park) will be ~6-9k a month with ~3k a month in taxes/maintenance.
The (made up) cocktail price index is also illustrative and in NYC one cocktail is ~$17-20 and DC is ~$11-14.
If you are interested in the genuine impacts and not a hyperbolic, emotionally charged discussion best left to pundits, then below are some areas I would suggest researching and conducting your own thought experiments. A good exercise is to pretend if you were a CTO presenting to the CEO the tradeoffs and risks in cost cutting.
- impact on reliability (sum across users for key metrics, not anecdotal evidence)
- systemic risk changes, measured using probability of a rare event
- feature velocity, volume of features, 'width' of features (how_many_bets x feature_surface_areas)
- the durability of systems engineered for reliability or "did we build systems that will survive if everyone leaves"
- revenue
- advertiser satisfaction with the technical platform
- impacts to internally maintained systems
- impact of loss of institutional knowledge
- impact of further attrition post-RIF
- compliance
- rate of progress vs competitors as an advertising platform
- rate of progress vs competitors in social media
- (related to above two) ability to maintain competitives advantages with reduced headcount
I read it a while ago and while I can't recall what was said exactly, I remember how I felt while reading it and how strong it was. The mark of a good book.
I had a very stable job already that I was perfectly happy to stay at. This meant that if I interviewed at other places I could negotiate from a position of extreme strength.
So I did exactly that. I interviewed at places and when I reached the offer phase I asked for a lot. The first offer I got was not good enough, so I didn't accept it. The next one I was able to convince them to let me work four days. It was written in my offer letter and everything. I signed it, and have been working 32 hour weeks since July.
Not OP but I’d recommend looking at the r/FIRE, r/LeanFIRE, r/ChubbyFIRE, and r/FatFIRE as starting points for how people in various situations retire early, often by scaling from 5 workdays to 0 workdays over time rather than abruptly in the traditional retirement context.
If your goal is maintenance mode for the company, milk profits for 10 years, and to be eventually replaced by competitors then I think you can run a company very slim. The other question would be, if you have captured a large market share (100s of M/yr to Billions in revenue), how many employees do you need to prevent an upstart from overtaking you through improved tech, product, or strategy?
For example, if FB never invested in ML they would have had even larger margins (fewer GPUs and ML engineers), but now that investment may pay off by fending off tiktok through copycat products and also rebuilding ad attribution after ATT. To complicate matters, before it happens, you don't know in what area your competitor will arise (ML? Product? Paradigm shift?). Similar examples with Google vs. OpenAI, ~2010s Kubernetes wars between cloud providers, Snap vs. FB/Twitter, etc.
If you compete with startups with tens of employees - shouldn't you use tens of employees to counter their strategies too?
Do you need endless hanger ons in HR, PR, all kinds of non-producing departments?
Crappy CEOs, which is not the same as a crappy founder, have grown companies without any sense and purpose. Daniel is a great founder and rode great luck. But, he should have been replaced with a Eric Schmidt operator figure a while ago.
I think the founder clings to company forever is coming to an end, in most cases going public should mean a new CEO.
A few thoughts. The first is, are we asking the wrong questions? Should it be, "If I spend 10m on hardware for predicting ads (storage/compute) that generates 25m in revenue, should I buy the hardware?". Sure, we can "minify" twitter, and it's a wonderful thought experiment, but it seems devoid of the context of revenue generation.
The second is, it's interesting to understand social media industry wide infra cost per user. If you look at FB, Snap, etc. they are within all within an order of magnitude in cost per DAU (DAU / Cost of revenue) of each other. This can be verified via 10-ks which show Twitter at $1.4B vs. SNAP 1.7B Cost of Revenue. The major difference between the platforms is revenue per user, with FB being the notable exception.
Also would you summarize the patent/architecture? The link is a bit opaque/hard to read.
Note: Cost of Revenue does also include TAC and revenue sharing (IIRC) and not just Infra costs but in theory they would also be at similar levels.
The basic idea of the system was to scan a reverse chronologically ordered list of "user id, tweet id", filtering out any tweet whose user wasn't in the follow set (or sets in the case of scan sharing) until you retrieved enough tweets for the timeline request. There are a bunch of variants in the patent, but that is the basic idea. At the time, I estimated that Twitter was spending 80% of its CPU time in the DC doing thrift/json/html serialization/deserialization and mused about merging all the separate services into a single process. Lot's of opportunity for optimization.
Interesting, 80% seems a bit on the higher end nowadays though? For example, Google quantified this as the "datacenter tax" and through their cluster wide profiling tooling saw that it was 22-27% of all CPU cycles (still a huge amount). They go a different route and suggest hardware accelerators for common operations. Datacenter tax was defined as:
"The components that we included in the tax classification
are: protocol buffer management, remote procedure calls
(RPCs), hashing, compression, memory allocation and data
movement."
Think of it this way: From mid-November to the end of December, there are two major US holidays where most employees will take one if not two weeks of vacation. Onboarding is an issue because you won't always have a full team in place to support the new hire. Vacation is an issue because new employees generally don't get any accrued vacation time, so you end up with idle, directionless, new employees for almost half the period. It's also easier to hide budget issues if you don't hire someone who isn't going to be useful anyway. It's just easier for everyone if you shut it down in November and start again fresh in January.
Yes, it is pretty common for hiring to pick up in January. Usually there are approved number of hires approved and they run out toward the end of the year and then many teams stop trying to hire until new headcounts are approved for the next January.
