seanpquig

He means don't anthropomorphize them with respect to pretending they have inherent desires, morals, sentience, etc. It's impossible to not compare the UI given them (conversational text) to human interactions since that's the inherent design.

Ahh thanks. I didn't follow the article links.

I personally hate the anthropomorphization of AI as much as anyone, but technically can't you make the same reductive argument about human consciousness?

It's just molecules, just atoms. Atoms, nothing bug atoms. Protons, neutrons, electrons...

Anyone know how this outcome is affecting Figma employees? I can imagine it's a huge letdown waiting 1.5 years for a big liquidity event and having it evaporate. Do employees see any benefit from that $1B termination fee?

I wasn't really meaning to criticize the blog post. It's very intelligent and interesting. I just think the title is kind of silly and highlights how extremely complicated and impractical advanced functional programing theory and concepts can be if this is meant to present them in a "simple" way.

Perhaps I'm slightly misinterpreting the usage of "simple" here and it's related to the more technical notion of simply typed lambda calculus.

Very interesting blog, but also kind of hilarious that a post about keeping a concept "simple" proceeds with a dump of insanely long, dense, esoteric code, variable names and jargon.

I love functional programming and have had some fun diving deep into some of the underlying category theory concepts at times, but I feel like 95% of the time trying to introduce these advanced concepts into a practical, professional codebase will lead to severe headache.

Databricks is a pretty good example of a huge company built around and open source project (Spark).

As someone who only does a frontend/full-stack project once a year or so, I do feel like some of this tooling mess is getting better.

On previous projects I remember the frustration of futzing with Webpack and Redux. Now it seems like React has matured and simplified nicely and Next JS is a beautiful framework with a great balance of flexibility + power with some reliable guardrails to work within and boostrap a basic React project.

Yea I don't think it's the only principle that should drive product development, but it helps ensure you're always solving real problems for your users.

There is still a lot of room for creativity once you've identified a class of problematic queries too. Especially as a search engine becomes more sophisticated, how you solve clear query failures can be a lot less straightforward, and clever features or machine learning are many times needed.

I will say there are clear exceptions to this inversion rule too. For example, we switched to a Learn-To-Rank system for our core ranking in the past year and we couldn't necessarily point to it clearly being the solution for problematic queries we were seeing, but it proved to unlock a ton of value and drive a lot of relevance improvements and surprising benefits in ways we couldn't necessarily predict for our specific use case and users.

I work on the algorithm for a widely used search engine and can confirm that this line of thinking has been very effective in improving our product over the years.

Rather than trying to generate hypothetical ideas for "how can we make our search better", we spend a lot of time analyzing our data to find where we are failing. Many of our biggest relevance improvements have come from tracking and understanding the types of queries where we consistently fail to generate results or user engagement.

I think it is a very effective approach, but can require some discipline and perspective. When you spend so much time focusing on the failures of your product, it can create this internal perception that the product is constantly failing and broken. So you do need to actively remember what you're doing well and how far you've come as a team/product.

It seems like a lot of the issues were around sharing code and libraries, resulting from isolated codebases per service and the versioning hell of shared libraries.

I work in a org that migrated to microservices over time, but intentionally adopted a monorepo approach as part of it. It works quite well and seems to avoid a lot of the pain points expressed here, while also gaining the benefits of microservices.

There are definitely tradeoffs to the monorepo approach. It makes development on shared libraries more delicate and stressful, however this can be mitigated by more robust cross-service CI, and I definitely think it's a worthwhile tradeoff to the painful cycle of shared lib versions diverging across services and finding issues when some service finally gets around to upgrading its version weeks/months after shared lib changes.

> If someone answers the question with a mainstream view, it’s possible that they just aren’t self-aware enough to know a view is well-held. To be self-aware means you ask questions of yourself, such as “how many other people also have this view that I think I alone hold?”

Is this really a characteristic of self awareness? Seems more like awareness of thoughts, trends, and opinions of others/society.

It's almost like the ability to answer this question perfectly, requires intimate knowledge of widely held beliefs/trends which may in turn have the opposite effect of selecting for people hyper aware of trends and others' ideas rather than those more deeply immersed in their own individual work, ideas and experience.

Glad to see investors are starting to push back on these ridiculous fees. For decades, the whole hedge fund industry, along with more traditional actively managed funds and financial advisors have been charging fees that can't possibly be warranted by the "value" they add.

I don't doubt that there are strategies and traders who can add skill-based alpha to broad market returns, but the catch is that it is essentially impossible to attribute performance to skill or luck. You may say consistently outperforming the market for 5, 10 or even 20 years is the mark of a great investor, but given the number of funds and players in the space, simple statistics would conclude such outcomes should routinely occur. You see it again and again where some manager has a remarkable run, raises tons of money, and proceeds to encounter mediocre/terrible performance. Some former "genius", do-no-wrong managers have actually lost way more client money than they've ever made because they attract tons of money after a lucky run and then proceed to tank.

The silliest part of the hedge fund industry is seeing all these funds and media retro-fit all kinds of rosy superlatives and sophisticated explanations onto a good year or two run, without ever acknowledging the likely role of luck and randomness.

Warren Buffets essay "The Superinvestors of Grahm-and-Doddsville" perfectly captures so much of this dynamic in a fun hypothetical exercise: http://www.tilsonfunds.com/superinvestors.html

Lovely long-form piece. Seems very analogous to the choice many tech companies face: focus on growing a moderately successful, proven model, or lever up to the gills with VC money and shoot for the moon. The later being sexier and higher status, but also risking catastrophic failure.

Mid NYC Hack day. This is mildly inconvenient...