921–930 of 1001 posts
Earlier quoted context omitted.
You can't write tests for the changes someone might make in the future.
That's exactly why you write tests. You want to be sure future changes don't break present functionality, especially if the future changes are being done by someone who doesn't understand your part of the system.
Earlier quoted context omitted.
To say he's learning on the job is speculation on your part. He's on the job, I'll give you that.
I mean, I'll give you that, I did chuckle. Frankly, this whole thing is a huge debacle and I can only imagine the context switch penalty being paid going from cars, to ISP, to rockets to Twitter. That said, I personally am astounded by Elon's tenacity. I would definitely not bet against it succeeding, but im not sure I'd bet on its success. If I had to choose though, I would bet on success at like 49/51 odds
Earlier quoted context omitted.
I’ll play the devils advocate here but frontend devs need to smarten up. This is basic error handling that should have been in place for years. Blocking tweets with 403 or whatever they chose shouldn’t trigger endless retries on short intervals.. ever!
You're right about error handling, but consider that the user who posted this was logged in. The screenshot they post is of a specific tweet, but they reference the home feed being down. What kind of API call was it making where it's asking for a list of tweets to serve to a logged in user and that call is not authenticated? It makes me think that the blocking was implemented improperly. Unless the home feed being do…
that is definitely frontend error
[flagged]
Earlier quoted context omitted.
What holiday is it?
Is this really easier than consulting a calendar? Its the weekend before the 4th of July, the independence day for USA - many employers give employees Monday and Tuesday off, creating a potential four day break during what is typically very good weather - that being said Twitter is presumably (still) an international company with people in all different holiday areas.
Earlier quoted context omitted.
[flagged]
You seem to be positing that there are two choices: 1. Work for a toxic dictator who makes bad, micro-managed technical decisions and then expects his engineers to work a holiday weekend to clean up his mess. 2. Never ship code, ever. I'm pleased to report that most software engineers exist happily somewhere in between these two extremes, and I would recommend you find a new job if you don't.
You seem to be assuming that people working at Twitter don't have the ability to look for another job, if they are unhappy.
Earlier quoted context omitted.
> So about the only thing they could do was issue multiple, parallel requests and hope that at least one of them was fast. lol nobody would do this to solve this problem because it doesn't even remotely solve it or give the appearance of solving it, if anything it's guaranteed to make things go slower
Google did this a long time ago. It’s more nuanced than you think. Two requests would be issued and the first acknowledged one cause the second to be cancelled. There was a public paper on this from Dean iirc and the method is a decade old.
Earlier quoted context omitted.
[flagged]
Ooh, good idea. People can go build something against the Twitter API! Oh wait! I'm absolutely going to keep enjoying Musk's comeuppance. In this, consider me a traditionalist. As the Greek tragedies show, people have been enjoying the just punishment of hubris for thousands of years.