It's not that the best performers are magical prompt engineers providing detailed instructions: They ask better questions that the LLM knows how to try to answer, and provide the specific information that the LLM would take a while finding. It's as if some people just had no "theory of mind" of the LLM, and what it can know, and others just do. It's not a living thing or anything like that, but it's still so useful to predict it, put yourself in it's shoes, so to speak. Just like you'd do with a new hire, or a random junior.

A place like Google has to be so much better off just training library concepts in, given how much of the things the LLM will "instinctively" reach for are unlikely to be available. Not unlike the acclimation period what happens when someone comes in or out of a company like that, and suddenly every library and infra tool you were used to are just not available. We need a lot more searching when that happens to us, and the LLM suffers from the same context issue. The human just has all of that trained in after a 6 months, but the LLM doesn't.

This second effect happens in all kinds of places where you have to jumps througha lot of hoops to just get to get there. Every hoop discards candidates, and promotes different things. Sometimes in ways that make sure that nobody capable of attaining the job is fit to actually do it well. You can see the issue all over the place, once you track people's careers. Sometimes things that should be disqualifying for a role are actually requirements in practice.

I prefer an intermediate solution when I can get away with it: Localize the mutable Java objects as much as possible, and just make sure that I don't leave a team/teammate that has little Scala experience all alone for a while. This often leads to styles that might be frowned upon by both camps of programming, but in my experience, dropping to imperative code when FP solutions are harder to optimize, while making sure that mutability is well contained and doesn't cross interfaces is Scala's happy place. Depending on the work to be done, each codebase can be pretty FP heavy, or be mostly imperative with an FP facade.

The real trick with Scala is really library design though: It's very easy to make a new library that has dozens of new concepts and is hard to learn and use, all while exposing things like Shapeless HLists to the outside world, while libraries that are easier to consume and don't crush compilation times through type magic are often tougher on the author, leading to more code generation and macros. Most library authors know so much Scala that they don't realize that just using their library well incurs in quite the mental cost to new developers.

I guess that if Amazon threw a crazy enough amount of money at them, then sure, everyone has a price, but how is joining Bezos' empire helping them? There's very little synergy in the other direction, so the premium for such an acquisition would have to be very large.

When you put the premium there, along with how being acquired by Amazon makes the competition more attractive, makes me think that something like that is unlikely.

Given how Stripe seems to build products in a lean way, it'd not surprise me if they are just launching like this and measure customer reaction. If the main reason it doesn't get the traction they want is the 48 lag, they'll just rewrite their reporting pipeline to use streaming, and the product gets faster for free.

So putting sophistication on your payments platform is something that you should only care about once you are very successful anyway.

A payments processor (old school or digital) is constantly taking on some certain amount of risk of fraud, from both the credit card user and the merchant itself. I could set up a store that appears to be real and just move my money out of my bank account and run. I could also go to a carding site, use real credit cards on my own fake store, wait for my transfers to process, cash out of my store and run. I could 'just' use it as a small operation to check whether my stolen credit cards are really working, and then make big purchases later... and that's just the very basics in merchant fraud.

Between this fraud, and risks from otherwise honest parties (what do you think happens when people preorder something, the company goes under, and the consumer tells the CC company that they want their money back? Someone ends up holding the bag), it'd be pretty much impossible to run a payment processor as a non profit center without a lot of work. Add to that that merchants want more complex features, like subscriptions, the effort to maintain PCI compliance, and that adding support for each new payment type and country is a pain in the behind for everyone, even for companies that do their very best to cut out every middleman.

So as long as you are interacting with banks and the risk of fraud is not carried 100% by the consumer, bitcoin style, you'll have a lot more innovation than you think, most of it dedicated to making life harder for fraudsters, and you'll find that this is something that you have to do for-profit. I'd not even consider doing it without venture capital, because you need a bankroll to handle the fraud losses which will definitely happen.

If you want proof of the innovation going on, just ask any fraud forum out there: There were plenty of people with nice and easy ways to defraud online processors, but nowadays, for all but the best fraudsters, it's a whole lot of effort for very little compensation.

And still, I'd not be caught dead carrying the amount of risk that someone like Braintree or Stripe is carrying on a regular basis without a profit motive.

In any situation with a broken status quo, openness by those that disagree will just get them squashed. In practice, change occurs in the dark: The people that have a different idea hide in a corner, bake the idea in secret, build allies in secret, and only reveal it when they cannot be squashed down. It works with different ways of investing, with tolerance to LGBT, interracial marriage... instant openness in an environment that is against you will ruin you unless you are powerful.

The principles, as applied, lead to an appearance of openness, where people have to toe the party line and only disagree when they know they can win politically. Otherwise, the powers that be will find you and make sure your disagreement can't go anywhere.

And how do you get power? In practice, by toeing the party line. Only by agreeing with the people above you, those that have been blessed as the smartest, you can get any credibility. And yes, this is something that is actively codified in Bridgewater's culture.

I wish external researchers had access to the internal ratings and surveys that Bridgewater employees fill in all the time. The patterns in them are the definition of a dystopia and groupthink.

I won't mention the signal because I want to keep my job. However I'd be surprised if there weren't at least a dozen companies that have access to some honest signal with such a good sample of the population at large as to be better at predicting the election than any pollster.

I had one of our most senior engineers, who has worked in this language's compiler, to try to solve the exercise. Instead of 40 minutes, it took him three hours!

If a candidate is going to interview in a language, for the love of god, have as a prereq that the interviewer is actually capable of doing the exercise in that language.