Bits and Bobs 6/10/24
1In the beginning of the film era, everyone just filmed stage plays.
It wasn't until much later that we learned the power of framing, montage, and other dynamics unique to film.
Using LLMs for human-like tasks is like recording a stage play.
What kinds of non-human-like tasks will LLMs be good at?
2The grammar of Lego bricks can cover a huge universe of things.
And yet not all conceivable things.
The LLM will not come up with new blocks.
But it could decide to use the frog brick to make a blossom on a tree.
That is, the LLM could decide to use existing "blocks" in novel ways.
3Every metric can be gamed.
A web of metrics that cut across different dimensions are less easy to game than any one metric.
In an organization, it's tempting to find the one most important metric and then just focus entirely on optimizing it.
The metric-maximizing playbook.
This is dangerous!
If someone proposes metrics maximizing, instead of saying "Here's why that metric you proposed has problems"...
A "No, but" stance
And also, every metric has problems when optimized in isolation.
… say, "Yes, and we should add these orthogonal metrics, too."
6Even if you're right as a system thinker on the multi-ply effects, it will take a long time for them to actually be validated.
In the meantime you could go bankrupt in that position.
Even when it does come true, it will be so indirect that people who weren't paying attention will say "well that was going to happen anyway" or "I didn't see you do any heroic action that directly caused that, you just got lucky"
Another example of "the market can stay irrational longer than you can stay solvent"
7Companies don't make strategic choices in a vacuum.
They post-hoc rationalize the thing that already roughly works for them or the position they're already backed into.
They might proclaim loudly "This is what the future will clearly be" (based on extrapolating their own current cost structures).
That should be read more like "Boy, I sure do hope that the things I'm good at become increasingly important..."
Companies understand their own strategy by retconning what they've been doing.
And that retconning strategy isn't done in a vacuum, it's influenced by what others think they're doing.
For example, what Stratechery thinks your strategy is almost certainly influences what your strategy actually is.
In a slime mold of an organization, a strategy that sounds plausible (based on a savvy external analysis) is one that everyone knows everyone else has read, and it can become increasingly true in the organization, as everyone acts just a little bit more like it's true, assuming that's how others in the organization will act.
8The net motion of a swarm is the sum of motion of all members of the swarm.
If the swarm is randomly buzzing, brownian motion, then the sum of vectors nets out to zero.
But if there is some asymmetry in the swarm's vectors, then the overall movement of the collective can become significant.
If there is a small but consistent asymmetry affecting every member of the swarm, the asymmetry might not even be visible at the level of the individual.
Each individual's local context and situation will dominate that small asymmetry.
But nevertheless, at the level of the collective, a massive vector emerges.
9When you have brownian motion, you can have a ton of energy going in, and basically no net outcome at the level of the collective.
The brownian motion just sums up to no net movement.
Just swirls of expensive chaos producing nothing but waste heat.
At the level of the collective, nothing observable changes.
10People assume that swarms can't have coherent results because they can't be controlled
But you can have coherence without control.
You must design for emergence.
Not what is the plan, but what actions will make the thing I want to happen more likely?
You can orchestrate swarms by understanding their physics, and then using them to create asymmetries.
11Things that are used are conserved.
We don't build in a vacuum, we build on foundations we find useful.
The foundations were left by other people before us, a form of stigmergy.
We build together without coordination explicitly, leaving hints of our judgment and ability for others to respond to.
Swarms are not just Brownian motion.
It's only in the very short term they look like that.
If you look closely, they grow things.
Look at the Sea Shanty TikTok meme trend of 2021.
No one organized it, it emerged organically.
Tons and tons of creators remixed various clips they liked.
Most of the remixes were not very good and were quickly forgotten by the swarm.
But some subset of the remixes were found to be good by some subset of the audience, and those were the ones that were more likely to be seen more often and then also remixed.
The swarm accumulated some significantly high-quality remixes by building on the best branches of the evolving swarm.
Interesting and distinctive things emerged, without any coordination.
Everyone in the swarm just used "yes, and" energy… but they applied their judgment to decide which foundation to build on.
That collective judgment applying process creates significant value, greater than what any one member of the swarm could have done.
12Swarms are open ended.
Agents choose to join the swarm when they think it's doing something useful that they want to be a part of.
What I've called a "positive boundary gradient" in the past.
People on the edge of the swarm would rather be in than out, which leads to the swarm growing.
Swarms tend to get momentum that becomes self-sustaining.
People who are aligned are more likely to stay and join.
People who are not aligned are more likely to leave or not join.
People who are somewhat aligned are more likely to become more aligned over time.
13Consensus swarms do a poor job of unlocking the value of data.
A consensus swarm is one where the swarm can only output things that everyone in the swarm likes.
Different teams have to decide to prioritize features that will benefit some subset of users.
Very few features are obvious wins; the more impact they have, the more likely they are to be for very small audiences.
Consensus swarms need to coordinate to a single answer that everyone on the team can agree with.
This reduces to blandness, or more likely just swirling around, never agreeing on anything.
Many useful use cases are too small a niche for a bespoke app to ever be viable, or for a FAANG PM to bother prioritizing it.
A non-consensus swarm over a cloud of data could find interesting pockets of value.
But as a user, you can't trust a non-consensus swarm of unknown actors to see your data.
What if there was a privacy model that allowed the non-consensus swarm to build things with your data, safely?
14So much of what has been built in the last 30 years is part of the same-origin edifice.
Every individual block that is added to the edifice is useful, but extends the same underlying logic.
If you're trying to build something that has different laws of physics at its core, it can't be part of the edifice.
In that case you can reuse some old blocks from the previous edifice that happen to be useful in a new combination, but you can't simply extend the edifice.
You have to build a new, small, edifice out of existing components, and hope that it is viable.
A seed crystal for a brand new universe.
15Encrypted data that is public has a lock that will automatically open at some point in the future.
It's locked now… but in the future if someone cracks that encryption scheme, then all public data encrypted with it, which was previously private, becomes public.
Luckily lots of data has a short half-life; in the far future when the lock pops open, the data's ability to harm will have been curtailed.
16Fields (e.g.
Fields (e.g. images) are hard to express in a linear stream (e.g. words).
"A picture is worth a thousand words."
Computers can do a formal description of the picture in a stream because they're very precise and infinitely patient.
Just streaming the pixels off left to right, top to bottom.
Maybe with some fancy math to do lossy compression.
Humans could theoretically do that, too.
But it would take an inhuman amount of patience and time.
So we generally distill the picture into high level descriptions: "a tree on a green hill and a blue sky with a labrador retriever puppy under it."
That's what makes it what Wittgenstein would call a field: quick to absorb, slow to describe.
Orders of magnitude difference between absorbing and describing.
Knowhow is also a field, a vibe.
Unlike pictures, it doesn't exist in some reified form to transcribe.
It is an amorphous, shifting blob that's hard to pin down.
Even if you're infinitely patient, it will have drifted to a new shape as you transcribe it.
At least an image will stay still for a computer to painstakingly transcribe. Knowhow won't.
Knowhow is a nebulous field, impossible to pin down to describe fully.
17When your users do something that surprises you, investigate.
The fact you're surprised implies your mental model of what they want is wrong.
18There's a huge advantage in sensible defaults as schelling points.
Especially in a system where things one person wrote need to interact with another person's thing in some way.
Instead of two users needing to coordinate to find overlap to work together, everyone can just get the default and unless they change it it will be compatible.
19In the same-origin paradigm, every origin is a pocket universe.
Each pocket universe starts with a few bits of functionality provided by the browser, but has to bring most of its own functionality and data.
Each universe must implement from scratch a lot of obvious functionality (or import it from a library).
Because this functionality is done "in user land", it's hard to coordinate multiple origins to use the same one.
Each origin has to recreate many parts of the universe individually, and any functionality that could have a kind of network effect with more use can't get off the ground.
The vast majority of functionality that is specific to a given experience is thin and small… but every origin has to reinvent the world anew in their own pocket universe.
So much duplicated effort!
20Every time you see a calendar widget, it should show your personal availability on it.
When we book a flight, you have to cross-reference your personal calendars to make sure you picked the right days.
Why doesn't this ever work this way today?
Each origin is its own pocket universe that knows everything about its universe and nothing about the other ones.
No individual origin has the data to show you your availability in their widget.
And as a user you wouldn't want every origin to have that data.
The friction of deciding to upload your data for such a feature is just too high for any origin ever to prioritize building this feature.
Why don't browsers add it as a feature?
Browsers are too low a pace layer.
It's not clear how to make a one-size fits all widget for this kind of thing that is generally useful.
This kind of functionality should be built in user-land, where more variations can be tried more quickly.
In user-land a swarm of possibilities can be tried, versus a single feature in a coherent product, which is a consensus swarm.
Browsers would have to add functionality to import availability in some way, and it's not clear how to do it.
Why don't extensions exist to do this?
Presumably some do.
But a user would have to be extremely motivated to choose to find an extension that does this and then install it.
This use case is a minor annoyance for everyone, a major annoyance for no one.
You'd have to trust some random extension author with that data.
And also, the extension would likely inject the information in a way that the origin could read back if it wanted to.
That is, the availability isn't fully isolated from the origin.
This kind of feature is one that we haven't even dreamed could be possible in the same origin model.
Imagine if every experience you interacted with was fully customized to you… and you didn't have to worry about your data flowing out to random sites you didn't like.
23If you handle the extremes the middle takes care of itself.
Think of extreme cases not as edge cases, but stress cases.
24When training a model, it's important to keep the test set isolated.
Every time the model interacts with the test set, a little bit of it is absorbed.
If you included the test set directly in the training set, even a model that overfit would look amazing, because it would look great at the subset of data.
You want to have the model only interact with the test set rarely and indirectly, to avoid being tainted and absorbing the test.
A similar thing happens with differential privacy.
Differential privacy guarantees work best for single-shot interactions with the data.
If you interact with data that has been prepared in n different ways with a given epsilon, you can still extract quite a bit of information about the underlying data.
25User data is radioactive.
Powerful, but dangerous.
Requires careful handling to not mess up.
When you take on someone's data, you take on responsibility for caring for it properly.
In many cases, developers would prefer to not have their users' data.
But there isn't a good way to do this in the same-origin paradigm.
The one exception where developers will want it: if they are trying to build a data moat.
Users upload their data to that system, and since data is hard to port out, they stick to that service more tightly.
A dangerous bargain!
26The memes that go the most viral are the ones that are generally useful.
Capturing some specific concept or idea in a striking way, that is also applicable in many contexts.
The more contexts it's useful in, the more likely the meme is to be shared.
The more a meme is shared, the more likely someone else is to find it and think to use it in another context.
28Two ways truth comes out: anonymously, and posthumously.
This quote is often attributed to Kurt Vonnegut.
29Some beliefs are wrong but still help you do the right thing.
"Porcupines shoot spines" isn't true, but what's the benefit anyone gets from testing that assertion?
Porcupines don't shoot spines… but also their spines are much more likely to catch you from a surprisingly far distance if you aren't careful, so why get close?
Metaphorically true, as opposed to really true. But still helps the right thing happen.
30Plugins are a tragedy of the commons for performance
A common loop: "this new tool feels so fast, not slow and bloated like the old tool.
Then it adds features and the user installs plugins and it slows down.
31There are two types of solvers.
Solvers of puzzles.
Solving complicated problems.
Solvers of mysteries.
Solvers of complex problems.
The latter is 100x more challenging and useful than the former.