Capital costs starting to dominate doesn't mean that they increase.

If capital costs are 10 and operating costs are 90, but later operating costs become 1, the capital costs remain 10 and the price to recover the capital costs is the same.

Of course the capital costs need to be spread over less kwh, so the kwh will become more expensive, but what matters is the avg (and thus total) cost paid, and that would be lower.

E.g.

5B in capital cost for 25MW (amortized in 25 years), and 30 per MWh in gas cost.

If you produce 180TWh (20h daily of production) the average price cost will be (5'000'000'000/25 + 180'000'000*30)/180'000'000 = 31 per mwh.

If you produce 36TWh (5h a day) the average cost is 35, but the total cost is significantly lower.

At the limit, if the power plant produces 1MWh in the whole year, it will cost 200'000, but paying that MWh that high enabled the system to pay for all the rest of the year the electricity at less than 31. You need to look at the total cost paid in the end by users, not at the marginal costs in some situations.

It's an auction, it's called marginal pricing. Every producer bids for x KWh at a certain price (for each time slot), and the cheapest y KWh to cover all demand are taken, and all are paid at the price of the most expensive KWh bought. There is plenty of economic research on auctions and why this system is optimal: this system incentives to bid at the actual marginal cost of producing electricity, and thus allows to discover the optimal price. EU has been discussing about changing it, but there hasn't been a better system proposed yet. If you change to pay at the bid price, you'll have companies build teams of analysts to predict the market price and bit at that, they're not just going to accept being paid much less of what they could.

Instead of focusing on this, here a few more impactful things that would help: 1. Zonal pricing, so that there is an aligned incentive to build production where demand is (connection to the grid is a big limiting factor) 2. Stop providing contracts to renewable where curtailed production gets paid (curtailed energy is paid by consumers as taxes on bills normally) 3. Start allowing to build more renewable so that renewable are setting the marginal price 4. Push utilities to do PPA (power purchase agreements) with producers of RE so they can agree to a fixed price, and a smaller slice of electricity is bought at the auction

There are a few more, but these are the most important.

Regarding your edit: the gas plant is not subsidizing, the customers are paying. But of course at the moment building renewable is so lucrative thanks to this setup, that there is a big incentive to build them. Of course they need to plan for 20-30 years, and the risk of getting to big periods at 0 marginal pricing is real, so builders need to evaluate well the risk (and PPAs can help)

In a non-competitive world what you say would be true (you'd avoid filling in the remaining 1%), but there are a large number of power producers that a cartel is unlikely

Not only that, after X months of not paying the landlord can request an eviction, and from the moment the eviction is requested to the moment its executed the government pays the rent to the landlord (I believe 3 is reasonable for X, but it can be higher or lower).

I'm a renter and always have been a renter, but it has always been crazy to me that the cost of people without a house is dumped on the unlucky landlord. If the decision is that this cost must be put on society, at least it should be spread among all citizens/landlords (e.g. with a tax on rent).

Not having the government paying while waiting for the eviction is the same as now: the government can just take ages.

The risk to landlords when the renters doesn't uphold the contract needs to be limited. This is also the reason why an insurance would be an inferior solution: there is still no incentive for the government to intervene fast.

We might find out that it's preferable to build social housing rather than paying rent to landlords, and the government starts actually doing something about it

Catholicism has been in general against contraception. Of course it's still used, but probably at lower rates. Non protected sex leads to pregnancy at a much higher rate than protected one. I expect it to be similar for other similar religions. Bodycount is also irrelevant, the total numer of intercourses is what matters. I'm not sure if having a stable partner since a young age leads to more total intercourses than occasional partners, but I'd be lead to thing so.

https://en.m.wikipedia.org/wiki/Religion_and_birth_control#:....

This comment consider employees (people) as if they were algorithms to maximize personal revenue.

That is not necessarily true. If FB where a place where people could feel proud of the good it does, a lot would be ok taking a pay cut.

Sure, maybe the ones that care the most about compensation wouldn't join, but that might be ok.

I worked previously for a for-profit company which was devolving a massive amount of their profits to charity. It was something I was proud of, and a part of my evaluation of how much I liked working there.

Message a recruiter working with the company (internal recruiters for example), they are litteraly searching for people, they'll be excited that a candidate reached out.

Of course some don't answer, but it's not a big number

> The article talks briefly about mocking your database: definitely never do this.

I definitely recommend doing this for same tests: it's the only way to check how your application behaves in case of failures.

The best thing would be to have a DB where you can inject failures, but I'm not aware of any. So test - the happy path on the real db - the sad path on the mock/fake (which might be a light wrapper around a real db, but with the ability of injecting failures)

That's true: the one place where it's a good idea to mock the database is when you want to simulate what would happen if a specific database error occurred that can't be triggered another way.

Like some people, I was expecting to find a way to have the advantages of a monorepo while having projects in separate repos. This is something Bloomberg is doing, and it's very cool. Each project is a separate repo, but they have a central integrated "repo" with all the repos, which is the "source of truth", and were code is built and deployed from. You can commit changes in your repo, and then you "release" the code into the integrated repo, which will rebuild all the transitive dependencies and run their tests to make sure everything still works. If anything fails, your release of the code is not merged in the repo. I'm now working with a monorepo, and I much prefer the Bloomberg approach. Cross repo changes can be made atomically (you update the reference in the integration repo for multiple individual repositories at once), and that is usually the big sell point of monorepo. And it doesn't have the downsides of the monorepo. The only issue is that it's not very ergonomic, and there isn't a tool to make that easy. But building such a tool is definitely easier than implementing a virtual FS as it has been done in multiple companies.

I'd love if someone still working there were to write a nice post about that system, it was the first of such a kind I saw.

> Each project is a separate repo, but they have a central integrated "repo" with all the repos, which is the "source of truth", and were code is built and deployed from.

That's exactly one of the things josh can already do for you :) Josh's concept of workspaces is precisely this: define your dependencies (no matter where else they originate from in the monorepo) and then check out only those dependencies, along with any code that solely exists in the workspace. Your workspace checkout is effectively the "bloomberg"-style repo setup you described, as you only see your code and the code of your dependencies, but when you push, your changes get added back to the hidden, backing monorepo (the source of truth) where all related and pertinent tests are run, and your change can only be committed if those tests all pass.

Thus, your commit is your "release". Sure, you don't have exactly the same workflow, as there's no difference then between a commit and a release, as by your definition you don't release after every single commit, but the whole "release this change to everything else in the monorepo" is touted as one of the benefits: there's no massive integration headache if you have multiple breaking changes which you then need to work on resolving for everyone else.

source: I work directly with "chrschilling" - who wrote josh

But that only works in one direction, no? So it works if you can develop your single repo, but it doesn't help you when you depend on other projects.

I think the best approach would be to have bidirectional links between the projects (if A needs B, then A has the stable version of B and vice versa). The point in that setup would be that "upstream" projects can notice when they are about to break tests in "downstream" repos and act accordingly.

They do, the repositories define dependencies, so when you change something everything that depends on you is rebuilt and tested. This prevents breaking changes, both for your dependencies and your reverse dependencies, identically to a monorepo.

It's a bit complicated to explain, but it works. That's why I hope they'll make a blog post :)

> I'd love if someone still working there were to write a nice post about that system, it was the first of such a kind I saw.

I don't know how far back you saw the Bloomberg system, but at this point it's basically the same as the Debian system (as in, debian/ subdirectories, .deb files, etc.). Versions of git projects are published as tarballs (source packages). Then sets of published projects are "promoted" and all projects that transitively depend on them are rebuilt and unit tested in a sandbox environment. If that process fails, the promotion fails.

Each source package can use any number of build systems, implementation languages, or project structures.

There's also a legacy subversion monorepo with a monolithic build system that builds on top of that, but it's slowly being phased out.

All that is an integration build including thousands of discrete projects. Those projects typically have additional CI/CD enrollments outside of the integration build system too.

This is what I saw. But I think it would be good to share the experience of a big, mature company with it to show that it's a system that can work, and can be easily added to companies which currently have a multi repo approach.

Also, there are quite a few tools to manage the distributions, and it would be great if they were open sourced. Basically Bloomberg championing their approach, to gain the usual advantages of open source (developer familiarity, cooperating across companies for improvements, and so on)

> Those projects typically have additional CI/CD enrollments outside of the integration build system too.

Another thing to call out is that you can simulate the "promotion", so you can check in your PRs whether your change is going to break any dependency or dependant.

Bloomberg let you do philanthropy work during working hours, and they assign you some amount of money depending on the hours you do that you can donate to charity.

I met a few people during such events, which is more or less what you say: you are with people from the company (not necessarily teammates, we did it as a team only once) and you might be helping public parks clean, or take trash from canal on a canoe, or sort food in a food shelter. It's a nice way to take a break, meet people from other areas, feel good about something you do, and managers have been very supportive of that, and they do it too.

I think that is a good balance of what you are talking about

They aren't criminal until the court system declares them criminal. The lawyer is defending them before they are declared criminals. That is what "presumption of innocence" means. Everyone has the right to be represented in court, even people that later on will be convicted. Otherwise we can just go back to use pitchforks and similar (and actually it's happening on social media, and it's not looking good)