>Also the "Palestine" side of the warrants are against Hamas which also feels weird (Hamas is also not a signatory nation and many suggest that Hamas != Palestine).
The ICC prosecutes individuals not states, so there's no contradiction here.
>Given Palestine is a signatory does it mean they have to take action to extradite the Hamas leadership to face trial?
Yes
>What consequences do they face if they fail to do that?
There's no penalties built into the statute. It tends to have diplomatic blowback. See [1] for a prior example.
As a forecaster: It's fun! It's an interesting way to learn about the world -- rather than gathering inert facts, you're forced to integrate them into a mental model, and then your model is tested for its validity empirically. It's also difficult and competitive, if you like that sort of thing.
As a consumer of forecasts: There's good research that prediction markets and other forecast aggregators are the best technology we have as a society for quantifying uncertainty. Not everyone will listen to them, just like not everyone eats their veggies, but c'est la vie.
I don't think there's too much risk of self-defeating forecasts (where a low forecast lulls decision makers into a false sense of security) - at least not yet. They're still pretty niche.
I think the article focused on base rates because they're a relatively unusual and legible "trick" to coming up with a forecast, but really they're only one element of a forecast; typically a forecaster will think about many different ways to "attack" a question and synthesize them (somehow!). Choice of denominator for your base rate is very important also and can radically change the answer you get.
The sites which host these forecasting competitions correct for the bias against rare events through what's called "proper scoring" rules -- there's some specific maths to it, but the short version is that you're exponentially rewarded for being a correct contrarian and exponentially punished for being confidently wrong.
There are limits to that too, of course -- the folks in the article will "only" have made on the order of mid hundreds to low thousands of predictions, so roughly speaking, you can expect these people to be calibrated for 1% or 0.5% odds but probably not 0.1% odds.
The primary goal of most large organisations' dev blog is to attract potential candidates to the top of the recruitment funnel.
This picture appears to be (presumably) the actual team doing a team building activity.
This is both a reasonable choice given the inferred instrumental goals of the blog, and a honest reflection of (one part of) the team life, assuming it's a photo of the real team.
I've just learned, the term of art for energy cost factoring in labor, infrastructure, replacement, etc is "levelized cost" or LCOE and by that metric utility solar is indeed already cheaper than fossil fuels and nuclear power:
It looks like utility solar is currently ~33% the LCOE price per kwh of nuclear or 85% of the price of gas (CCGT).
This is an increase relative to 2021 (20% of nuclear / 60% of gas)
(As I understand it, the cost increase between 2021 and 2023 is from cost of capital and shipping)
Naively projecting out the LCOE trajectory, it indeed does not look like it's going to get to be 'dirt cheap' soon - eyeballing, the LCOE curve over time appears to be flattening towards a 5% or smaller cost reduction year over year.
As long as you believe you can acquire customers for some margin less than (you project) they will pay you across their lifetime as a customer, the rational choice to to maximise your money is to spend all the money you have (and more!) on acquiring more customers.
As a result, the majority of SaaS businesses aren't profitable, and people talk mostly about MRR.
The decision likely got made before performance was a major constraint.
As I understand it, Instagram is a python codebase and (guessing) may be the primary motivator here.
Probably the first, say, 100 person-years of effort poured into the Instagram codebase were done at a time when product development velocity, not performance, was the main priority.
It's not that bizarre. It's path dependence. They have an existing codebase with hundreds (thousands? tens of thousands?) of person-years of effort contributed in python already, so a complete rewrite would be too expensive to consider.
I'm not sure if this is the _main_ reason, but one thing that makes node_modules size more than an aesthetic concern is serverless.
Booting a serverless function with 100s of mbs of modules takes an appreciable time - to the point where some folks webpack bundle their serverless code
>It seems to mostly be a me problem, on reviews of other coworkers PRs her comment seem reasonable. That could just be not fully understanding scope or task at hand.
What do you think explains the difference?
* Are there ways you can explain yourself better that others are doing?
* Could the problem honestly be with your code being hard to understand? Could you simplify?
* Could you deliver in smaller chunks, that are each easier to understand?
* Is it about working on a tech or product area that they aren't so familiar with? Perhaps you can help bridge that gap with a lightning talk or some new documentation?
>I have not had a direct conversation as I'm not sure how to go about it or phrase it. We seem to have a good relationship and I don't want to potentially ruin it going about this in the wrong way.
You've got to place trust in your colleagues that you can have adult conversations about what's working well and what's not. It doesn't have to be a big deal!
It could be as simple as:
"Hey <name>, I feel like a few times lately PR reviews hasn't been smooth. Have you noticed that too? Is there anything you think I could do differently?"
>We have basic standards
One thing that could help here is improving your team standards for a PR author! E.g. at my company, we have a PR template which encourages you to add a screenshot/screencast of your feature working.
We also encourage adding test steps to our PR template, to make it easy for reviewers to try the thing themselves. Good test steps might look like:
* Run the app as normal
* Turn on feature flag XYZ
* Head to localhost:3000/new-page and click all the widgets
* You should see the widgets created in your db with this query:
It sounds like work, but it's probably the steps you did anyway before you put the PR up! so it's more of a mindset thing
I don't have answers but some questions that might help:
* Are their code reviews _of you_ poor in particular, or are they poor in general when reviewing anyone's code?
* Are they reviewing your code in good faith (and are just finding it challenging) or in bad faith (and can't be arsed or don't like you / the project / etc)?
* Have you had a direct conversation with them about it? (Is your relationship with them strong enough to enable that?)
* Do your team have standards for a code review? Expectations for an author and for a reviewer?
The ICC prosecutes individuals not states, so there's no contradiction here.
>Given Palestine is a signatory does it mean they have to take action to extradite the Hamas leadership to face trial?
Yes
>What consequences do they face if they fail to do that?
There's no penalties built into the statute. It tends to have diplomatic blowback. See [1] for a prior example.
[1]: https://press.un.org/en/2018/sc13623.doc.htm