Using your own data, then: can you present your evidence that the majority of MPs, CEOs, bankers, and newspaper editors are left wing?
273 karma · joined November 28, 2024
That's why it's the sole preserve of the elite, unlike Oxford.
There has never been an Eton-educated Labour PM and the majority of Labour MPs come from state schools. The political skew among the elites is pretty obvious.
- You sometimes win a bit along the way, but eventually you lose everything.
- The jackpot prizes are only there to lure you in, and you never win them. Towards the middle of the shelf are things like £20 notes. We noticed that one of them was getting quite near the edge, and might actually become winnable, but then the following morning its position had been reset to the back of the shelf.
- It's still fun as long as you're just playing with money you don't mind losing, and not expecting to come out ahead.
They even learned something about company scrip, from the tickets that come out of the machines and the ridiculous exchange rate between tickets and the actual rewards at the prize shop.
I asked my son on the way home if he'd put all his Christmas money and savings into the machine if I let him, and the answer was hell no - maybe a pound, but he didn't want to lose all of his money. Valuable lessons all round.
- You have to decide whether to bump the entire API version or only the /foo endpoint. The former can be a big deal (and you don't want to do it often), the latter is messy. Especially if you end up with some endpoints on /v1 (you got it right first time) while others are on /v4 or /v5. Some clients like to hard-code the URL prefix of your API, including the version, as a constant.
- You still have to decide what your deprecation and removal policy will be. Does there come a time when you remove /api/v1/foo completely, breaking even the clients who are using it correctly, or will you support it forever?
It's not easy at all, especially if you have to comply with a backwards compatibility policy. I've had many debates about whether it's OK to introduce breaking changes if we consider them to be bug fixes. It depends on factors like whether either behaviour is documented and subjective calls on how "obviously unintended" the behaviour might be.
> In 2014, Yuan et al. found that 92% of catastrophic failures in tested distributed systems were triggered by incorrect handling of nonfatal errors.
Typical example would be processing an event that you can't handle from a message queue. You don't want to crashloop, so you'd probably have to throw it away on a dead letter queue and continue processing. But then, is your system still correct? What happens if you later receive another event relating to the same entity, which depends on the first event? Or sometimes you can't even tell which entity the malformed or bug-triggering event relates to, and then it's a real problem.
Just do the task honestly and well.
I've been using Go on a large codebase for a number of years, and I haven't found data races to be a problem in practice.
I really like the idea, it sounds like a very healthy way to engage. If you took a photo on holiday you wouldn't be able to share it until the evening, so you'd just put the phone away. It becomes a camera. At the moment I see people take a photo and then for the next hour they're distracted by reactions, comments, feeling obligated to respond to comments... they miss the whole experience. Sharing when your friends are actually online would also be more interactive.
Of course, if you're on holiday then your three hour home time window may be unusable. But then, worst case scenario, you bulk upload everything when you get home. It would be like the old days of returning from a trip and getting friends round to see a slide show - quite charming, really.
How would you unit test those methods? You'd have to directly set the field values, then call the method, then assert on the fields. If the answer is "you don't unit test private methods" then that's completely fine, because I agree with that (perhaps this is implicit from the private keyword, I don't know Java). But I'm struggling to imagine how you would get to those private methods with such a strict adherence to TDD as Bob recommends. Methods like increaseEachPrimeMultipleToOrBeyondCandidate() are quite complex, and would be tricky to build up using TDD if you couldn't exercise them directly.
If nothing else, surely Bob's approach is not thread safe. Call PrimeGenerator3.generateFirstNPrimes() concurrently and they'll trample all over each other. John Ousterhout's stateless version doesn't have that problem.
I sometimes work in areas where the error budget is essentially zero, with an element of concurrency, and for those there is a design stage before the build stage. I could see the value of formal methods there. At least I could execute a model with a model checker, which makes it one step closer to the code than a design doc or RFC.
Full disclosure: I haven't actually used formal methods myself, I've just been interested in the idea for a while and have done some reading on it.
You can still call it fact checking, just as you can still call air travel by that name even though a very small percentage of planes crash. Suppose the fact checkers had a 0.1% false positive rate and a 0% false negative rate. For every 1,000 pieces of reported content they review which should be left up, they take one down, and they never leave anything up that should be taken down. Wouldn't we say that the system, broadly speaking, works and has value? Even though it doesn't always work?
Do you think Community Notes will "always work"?
> Community Notes is from the community, not from Facebook, so not directly influencable by the government.
It wouldn't work like this. Meta still own the platform, profit from it, and are responsible for it.
Governments will always want to talk to Meta about the material they host, because Facebook reaches millions of people. Sometimes the governments will have a valid case, like when material on Facebook can be linked to inciting genocide[1]. And sometimes they won't, and will be trying to pressurise Facebook for political or self-serving reasons. The point is, those governments will not simply be satisfied and go away if Meta throw their hands in the air and say "Sorry, but we fired the fact checkers and have no control over the material on our platform. It's up to the community, talk to them."
If Meta are trying to solve the government interference problem, the solution is to strengthen their fact checking and moderation systems. Then they'd be able to push back and say that actually no, they are confident that the content on Facebook is appropriate and can credibly stand by it. Abdicating responsibility is just going to get them into more trouble.
[1] https://en.wikipedia.org/wiki/Rohingya_genocide#Facebook_con...
It's also not necessary for third party fact checking to "always work" to have value, there will be some level of false positive rate that's still acceptable. Even with something like Covid, there is unambiguously false information with probably harmful consequences ("you can cure Covid by drinking a bottle of bleach", for example) that would be worth taking down by fact checkers.
> The concept of fact checking is a very recent movement, with the idea that we could filter out the "fake news" on the internet, which is also a recent concept.
Again, this is not accurate. Look at the job sub-editors have been doing for a century or more. Their main role is to save the newspaper from getting sued or looking silly by striking out or questioning any claim that can't be proven to be true, or corroborated by multiple sources. Fact checking is not a new discipline.
> When you grow up you start to understand that you can't trust all authority all the time.
I think you know I'm not arguing for this. Don't misrepresent my position, please.
Like any other work, it can be reviewed by supervisors within the company and/or the client (Meta). If a sample of an employee's work shows that they often hide content that isn't factually false, they are performing their job poorly. If Meta doesn't like the job the company is doing, the contract can be cancelled.
> If we could have legitimate fact checking that really works, then I guess we wouldn't need any politics at all.
You absolutely need both. Politics is about which decisions to make within the context of shared facts. The amount of the US national debt, the number of people caught crossing the border illegally in 2024, or the number of people sleeping on the streets in San Francisco are all matters of fact. What to do about them is politics.
Runna doesn't get everything right. It didn't seem good at adjusting your plan based on performance, if it even tries to do that at all. My first few weeks of runs were much too easy, and I had to experiment with manually generating different plans with faster and slower target race times until the zone paces seemed right for me. Would have been great if it adjusted on the fly and I could have kept the same plan.
Refactors, doc fixes, low priority bug fixes, and tech debt are all fair game for managers to pick up. I do think it's important to keep your hand in.
After a few years as a manager I switched back to the IC track. I sometimes wonder if my experience means I'm just hard-wired to be an IC, or if with more time and practice you can train yourself to get the dopamine feedback from management activities.
A Senior's work is scoped to one team, reporting to an EM, and they do the usual stuff - work on tickets, run stand-ups, deliver features. The Staff engineers have no home team (they are expected to work across multiple teams), they report to the CTO, and they have a lot more freedom in what they spend time on. In fact the dynamic is reversed; rather than being given work, they're accountable for identifying the most important work and doing it. It also comes with a whole lot of new meetings.
I'd argue that Senior Engineer is more of a bullshit title, if titles are supposed to be an indicator of what your job involves. At Senior my job didn't change at all. It's just a title to recognise people who have been around for a while.