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?
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.
I don't think your conclusion is especially fair. This is a blog post about programming language design and type theory not general usage of functional programming.
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.
The techniques present in the paper and blog post are not really from functional programming but from mathematics. Functional programming just happens to present them in the most natural way; this is why the paper chose Haskell. We could implement the same in any Turing-complete imperative language, but then the code would swell by orders of magnitude.
I think you are still making an unfair generalization from this post. What you are saying is like reading a machine learning paper which has python examples and complaining that software development with python demands understanding advanced linear algebra.
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.
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.
> 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.
This sounds a lot like the 6-sigma approach of driving improvement by focusing obsessively on eliminating "defects".
There are certainly huge wins that can be obtained by identifying and eliminating bugs or corner-cases with undesired behavior. But it's scary to imagine a world where this is used as a replacement for innovative thinking - ie, "how can we make our search better". If Steve Jobs had focused all his proverbial efforts on minimizing flip-phone defects, the world would have missed out on the smartphone revolution.
The iPhone's competition was not the flip-phone. It was the PDA and the Blackberry and the pocket PC. The iPhone was an evolution of previous similar devices.
I still do not understand why people consider smartphones revolutionary. It is revolutionary that everyone has one on them at all times, but the gadgets themselves aren't all that.
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.
That's why it's important to focus on effectiveness first. At any point in time you should know what you are trying to solve and why. The Inversion Principle is simply a useful tool to helps support that and figure out the how, but is by no means a silver bullet.
There's a huge potential in mining search data, especially if you can group top-of-funnel vs. bottom-of-funnel searches to see where failures are occurring. Segmenting queries like "zm950" against "shoes" or "nike" and seeing where gaps exist against user intent.
When it comes to zero (or near-zero) results, I've had good results using this to identify gaps in the current product offering and what visitors are expecting to be there. Two examples:
1) A seller of custom prescription glasses: top two search queries were "contact lenses" and "sunglasses". They didn't offer the former, they did sell sunglasses (most frames could take a tinted lens as an option) but didn't make it obvious with design, content, or marketing.
2) A seller of cabinet hardware (pulls & knobs): a large proportion of their top 10 search terms seemed to have a door hardware intent. Adding this missing category boosted sales without additional marketing dollars spent (the customers were already there and just bouncing when they realized the site didn't carry what they wanted).
These are all ways to focus on understanding failures instead of trying to optimize successes, which is often finding the local maxima.
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
To the extent that anyone is able to run a strategy that does beat the market:
a) they probably can't tell the difference between getting lucky and exploiting a niche
b) if they take on more capital their movements will be discovered and the strategy will fall apart
If you're well connected I'm sure you can eventually find a few funds trading on true insider info or novel strategies... but good luck getting in. As soon as the cat is out of the bag the party is over.
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.
