5 ms·

Clearly these engineers have never done customer feedback for developing nations, twitter interactions clearly provide evidence for what musk said, but some eng

by viig99 4y ago

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.

sho_hn 4y ago
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.
- viig99 4y ago
  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.
  - fragmede 4y ago
    Except that you can open the dev console in a browser and load Twitter.com yourself and you won't find 1000's of XHR requests.
    - sho_hn 4y ago
      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. The developer puts the real number at 200.
    - MonkeyMalarky 4y ago
      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.
    - viig99 4y ago
      RPC generally means server side calls, probably this https://twitter.github.io/finagle/ https://twitter.github.io/finagle/, and XHR is not RPC.
detaro 4y ago
Can you point to the "clear evidence" that "thousands of RPC calls" are the issue? Note that the dev didn't claim performance is good.
- david927 4y ago
  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.
  - detaro 4y ago
    So, "no".
    - david927 4y ago
      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.
  - MonkeyMalarky 4y ago
    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.
    - detaro 4y ago
      and indeed current management has been prioritizing new features :P
      - MonkeyMalarky 4y ago
        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.

by viig99 4y ago

sho_hn 4y ago

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.

viig99 4y ago
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.
- fragmede 4y ago
  Except that you can open the dev console in a browser and load Twitter.com yourself and you won't find 1000's of XHR requests.
  - sho_hn 4y ago
    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. The developer puts the real number at 200.
  - MonkeyMalarky 4y ago
    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.
  - viig99 4y ago
    RPC generally means server side calls, probably this https://twitter.github.io/finagle/ https://twitter.github.io/finagle/, and XHR is not RPC.

detaro 4y ago

Can you point to the "clear evidence" that "thousands of RPC calls" are the issue? Note that the dev didn't claim performance is good.

david927 4y ago
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.
- detaro 4y ago
  So, "no".
  - david927 4y ago
    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.
- MonkeyMalarky 4y ago
  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.
  - detaro 4y ago
    and indeed current management has been prioritizing new features :P
    - MonkeyMalarky 4y ago
      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.