Clearly these engineers have never done customer feedback for developing nations, twitter interactions clearly provide evidence for what musk said, but some engineers seem to be in denial, imho the firing is cause worthy.
Performance has been bad forever. Twitter has had forever to fix it. They haven't. By definition, the existing developers aren't smart enough to do it. The developer here is trying to throw smoke because he's embarrassed. He should be.
Or it could be that previous management was constantly prioritizing new features instead of performance gains and now he's getting unnecessary flak for it.
The worst thing is that by firing and laying off too many people on a team with so much legacy code, they might end up scrapping the app and doing a rewrite because it'll be easier than fixing it. So inevitably, it will run faster, and people will hold it up as an example of Musk being a "genius" . When really, it's exactly what the guy suggested doing, but instead of listening they fire him and force a situation where they have to do it anyways.
Blind assumptions count for nothing. If you actually read the tweet thread Eric (the former employee) gives a summary of the trade offs made that have given Twitter bad performance and suggested removing specific features to improve perf.
It doesn't matter if it's "thousands of RPC calls" or not. Eric's response is, "It's definitely not that! It's... well... we don't know... so just spend more money on servers." That response alone would have me fire him.
> By definition, the existing developers aren't smart enough to do it.
You have no evidence to support this. Performance sucks in other countries because product leadership with their hands on the wheel of the company never prioritizes "unsexy" investments in performance and infrastructure work (same as the new guy btw). That is exactly what Eric was advocating in his thread.
I think that's misreading the exchange. He was challenging Musk on the fact that "1000 RPC calls" isn't what's happening and isn't the reason for the slowdown in his opinion, but did not deny that there are performance issues - and even cited other reasons it's slow. I don't see the denial you see.
Said engineer, said 1000 RPC calls are not the issue, and when questioned further on proving a tracepath / perf result casually exited the conversation, to me it looks like they are not ready to do better or listen to valid criticism, leading conversations on semantics is just creating noise instead of acting on signals.
Also 1000 RPC's are a very valid performance bottleneck, 1000 * latency caused by serde+ network can compounds easily based on data locality + container network orchestration, no data was provided otherwise even when asked for.
Not to defend any of the catastrophe of management that just happened but can't both be true? Eric does say in his tweets that a lot of time is spent waiting on the network. If that is because server side, the endpoint handling a request is spamming other backend services with 100s of RPC calls it would be slow. Now, why you would call out your android dev. on why your backend is not responding fast, I dunno.
That's client-side requests. Musk was talking about internal RPC calls to microservices needed to ultimately respond to the client-side requests.
If the internal arch is heavy on microservices and you're putting together, say, 50 tweets you're at 1000 RPC calls with just 20 per tweet. It's not inconceivable.