Ben Kuhn: Be Impatient
2020 Jul 23
See all posts
Ben Kuhn: Be Impatient @ Satoshi Nakamoto
- Author
-
Ben Kuhn
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
June, 2017: my partner Eve and I are stuck at the visa-on-arrival
desk in the domestic transfer wing of Bole International Airport, Addis
Ababa. The rest of the transfer passengers, all Ethiopian, are waltzing
past us to form a monster queue at passport control. As soon as I get my
precious stamp, I sprint off to hold our place before more passengers
sneak in front of us.
Ten minutes later, Eve finds me, groggy from our redeye and
nonplussed about navigating the Ethiopian visa desk on her own. "Why did
you have to run off like that?!" Somehow, "so that we could wait at the
departure gate instead of in the passport control line" doesn't seem
like a very good reason.
It was at this moment that I realized I was an unreasonably impatient
person.
(In retrospect, I probably should have been tipped off by my
compulsion of doing a mental critical path
analysis on any everyday activity taking more than 15 seconds, but I
just thought that was normal until I started dating people and noticed
they often did things in a sub-optimal order.)
Now that I've confessed to the sin of impatience, I'm going to spend
the rest of this post trying to convince you that it's actually a good
thing.
(The good part is the habit of frequently asking yourself "how could
this thing take less calendar time." I don't recommend manifesting it in
annoying ways like ditching your partner in an Ethiopian airport.)
Being impatient is the best way to get faster at things. And across a
surprising number of domains, being really fast correlates strongly with
being effective.
Obviously, lots of these are non-causal correlations. Still, the
sheer number of different datapoints is a surprising convergence:
E-MAIL
It seems trivial, but lots of different people have observed that
being slow to respond to emails is a bad sign, or that famous people
whom you'd expect to be swamped respond surprisingly quickly.
Sriram
Krishnan:
the most famous, interesting, powerful people all read their own
email
they're almost universally good at responding to it
quickly
they're always very, very curious.
they have very little time. Anything with friction gets done
"later"
Sam
Altman:
people tend to be either slow movers or fast movers and that seems
harder to change. Being a fast mover is a big thing; a somewhat trivial
example is that I have almost never made money investing in founders who
do not respond quickly to important emails.
STARTUPS
It's become common wisdom that launching (and iterating) quickly is a
major factor behind whether startups succeed.
Sam
Altman again:
[Y]ou have to be decisive. Indecisiveness is a startup killer.
Mediocre founders spend a lot of time talking about grand plans, but
they never make a decision. They're talking about you know I could do
this thing, or I could do that other thing, and they're going back and
forth and they never act. And what you actually need is this bias
towards action.
The best founders work on things that seem small but they move really
quickly. But they get things done really quickly. Every time you talk to
the best founders they've gotten new things done. In fact, this is the
one thing that we learned best predicts a success of founders in YC. If
every time we talk to a team they've gotten new things done, that's the
best predictor we have that a company will be successful.
This propagates even down to the level of how quickly you deploy
software changes. Nick
Schrock on Facebook / Instagram moving fast and breaking things:
Instagram was even faster operationally than Facebook. They had
continuous deployment. Any engineer could deploy at any time (they would
run a command called "Yolout" lol). Facebook was on weekly deploys at
the time on the web and way slower on mobile.
IG story definitely lends credibility to the
those-who-ship-faster-win argument
...Worth noting that Facebook learned from this. As the company grew,
the release cadence got faster. First daily, then twice daily, and it is
now continuous. It's a remarkable achievement by the release engineering
team.
It's not just Facebook; Accelerate found
a strong correlation between deploy frequency and performance:
To summarize, in 2017 we found that, when compared to low performers,
the high performers have:
The "speed matters a lot" principle applies even to things that are
already very fast. Google has found that users dramatically prefer
faster webpages:
The BBC found they lost an additional 10% of users for every
additional second their site took to load.
DoubleClick by Google found 53% of mobile site visits were
abandoned if a page took longer than 3 seconds to load.
...
- When AutoAnything reduced page load time by half, they saw a boost
of 12-13% in sales.
James
Somers:
Google famously prioritized speed as a feature. They realized that if
search is fast, you're more likely to search. The reason is that it
encourages you to try stuff, get feedback, and try again. When a thought
occurs to you, you know Google is already there. There is no delay
between thought and action, no opportunity to lose the impulse to find
something out. The projected cost of googling is nil. It comes to feel
like an extension of your own mind.
Nelson
Elhage put it best:
What is perhaps less apparent is that having faster tools changes
how users use a tool or perform a task. Users almost always have
multiple strategies available to pursue a goal — including deciding to
work on something else entirely — and they will choose to use faster
tools more and more frequently. Fast tools don't just allow users to
accomplish tasks faster; they allow users to accomplish entirely new
types of tasks, in entirely new ways. I've seen this phenomenon clearly
while working on both Sorbet and Livegrep...
Many individual tests at Stripe would take 10-20s or more.... Because
we succeeded at building Sorbet so that it could typecheck the entire
codebase in that time window, it became the fastest way many developers
could get decent feedback on their code, to check for basic typos,
misused APIs, and other low-hanging classes of errors. Since it was
their fastest option, we saw users reaching for Sorbet as their first
line of checking their code fairly early on in our development and
rollout. Getting even mediocre feedback and some confidence fast was
much more important than anything that would take minutes.
Watching users use livegrep, I've seen a related upside from its
performance.... Because livegrep is so fast, users use
it interactively in a way I've rarely seen people interact with
other search engines: they enter an initial query, and then, if they get
too many or too few results, they edit it based on the result list,
which gets a new set of results, which they continue to refine or expand
until they hit on the results they are seeking.
PERSONAL WORKFLOW
Sam Altman:
I also made an effort to learn to type really fast and the keyboard
shortcuts that help with my workflow.
Steve
Yegge via Jeff Atwood:
I was trying to figure out which is the most important computer
science course a CS student could ever take, and eventually realized
it's Typing 101.
The really great engineers I know, the ones who build great things,
they can type.
This matches my experience at Wave, where the best engineers are
disproportionately likely to type quickly, know their keyboard
shortcuts, and have invested a lot of time making their common tasks
efficient.
Obviously, those aren't the main things that make them good
engineers—but I think they help in more than just the obvious ways.
NEGOTIATIONS
At Wave, when hiring, we've noticed that moving someone through the
hiring process faster makes them much more likely to accept our
offer. If we take a long time to get back to them or schedule the next
steps, it both gives them more time to lose interest, and makes it seem
like we're not excited about them. Not a good look!
This is apparently common trope in sales as well—"time kills
all deals".
Paul Graham on how the
founders of Stripe got time on their side:
At YC we use the term "Collison installation" for the technique they
invented. More diffident founders ask "Will you try our beta?" and if
the answer is yes, they say "Great, we'll send you a link." But the
Collison brothers weren't going to wait. When anyone agreed to try
Stripe they'd say "Right then, give me your laptop" and set them up on
the spot.
Fred
Wilson on the same effect in networking:
That night when I got home I told the Gotham Gal "I met Danny Meyer
today and he gave me his card and said I could call him whenever I need
a table." To which she replied "go there for lunch tomorrow." And I told
her "I don't have a lunch tomorrow." She said "Get one. He will remember
who you are tomorrow but won't next month."
COMBAT
One of the most influential military strategy writers, John Boyd, is
most famous for the idea of the "OODA loop:" that human action is an
iterated process of observing the
world, orienting within it, deciding how to respond
and finally acting on the decision. Boyd's claim was
that going through the OODA loop faster was a decisive
advantage:
In order to win, we should operate at a faster tempo or rhythm than
our adversaries—or, better yet, get inside [the] adversary's
Observation-Orientation-Decision-Action time cycle or loop ... Such
activity will make us appear ambiguous (unpredictable) thereby generate
confusion and disorder among our adversaries—since our adversaries will
be unable to generate mental images or pictures that agree with the
menacing, as well as faster transient rhythm or patterns, they are
competing against.
As a recent example, for instance, many states and countries waited far too long to lock
down when the COVID epidemic hit because the virus
got inside their OODA loop:
Right now, the perception of agency at all levels is falling.
Individuals, corporations, governments, heads of state, stock traders,
the UN, everybody feels they're losing the plot, but they don't
see anybody else finding it.... As far as we can tell, a virus
has gotten inside the OODA loop of Homo sapiens, and seized the
initiative, while we're struggling to figure out what to even call it.
It is spreading faster than our fastest truths, lies, and bullshit. A
supersonic shock wave in the narrative marketplace.
LIFE IN GENERAL
Patrick
Collison:
If you're 10–20: These are prime years!
People who did great things often did so at very surprisingly young
ages. (They were grayhaired when they became famous... not when they did
the work.) So, hurry up! You can do great things.
(He also maintains a personal list of fast
things.)
Sam
Altman:
Once you have figured out what to do, be unstoppable about getting
your small handful of priorities accomplished quickly. I have yet to
meet a slow-moving person who is very successful.
Why impatience?
There's an obvious way in which moving faster is important: if you're
10% more productive, you will finish your work in 10% less time, so you
can do 10% more work total. But I don't think that's the main reason
that speed is important.
It's worth pointing out at this point that all of the quotes above
aren't just about churning out work—they're about processing
information more quickly. The faster you process information, the
faster you can incorporate the result into what you do next.
In other words, the main benefit of being fast is that you end up
doing different things. Nelson Elhage's point—"having faster tools
changes how users use a tool"—applies across nearly every domain:
If you respond to your emails quickly instead of slowly, you'll
get access to more new opportunities, and end up prioritizing them over
whatever you would have done instead.
If you make it 10x faster to test your code, you don't just save
time waiting on tests—you can start doing test-driven
development, discover your mistakes earlier, and save yourself from
going down bad paths.
If you deploy your new app now instead of next week, you'll learn
how users like the new features one week earlier, and you'll be able to
feed that knowledge back into future product decisions.
That means that moving quickly is an advantage that compounds. Being
twice as fast doesn't just double your output; it doubles the growth
rate of your output. Over time, that makes an enormous
difference.
Ben Kuhn: Be Impatient
2020 Jul 23 See all postsBen Kuhn
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
June, 2017: my partner Eve and I are stuck at the visa-on-arrival desk in the domestic transfer wing of Bole International Airport, Addis Ababa. The rest of the transfer passengers, all Ethiopian, are waltzing past us to form a monster queue at passport control. As soon as I get my precious stamp, I sprint off to hold our place before more passengers sneak in front of us.
Ten minutes later, Eve finds me, groggy from our redeye and nonplussed about navigating the Ethiopian visa desk on her own. "Why did you have to run off like that?!" Somehow, "so that we could wait at the departure gate instead of in the passport control line" doesn't seem like a very good reason.
It was at this moment that I realized I was an unreasonably impatient person.
(In retrospect, I probably should have been tipped off by my compulsion of doing a mental critical path analysis on any everyday activity taking more than 15 seconds, but I just thought that was normal until I started dating people and noticed they often did things in a sub-optimal order.)
Now that I've confessed to the sin of impatience, I'm going to spend the rest of this post trying to convince you that it's actually a good thing.
(The good part is the habit of frequently asking yourself "how could this thing take less calendar time." I don't recommend manifesting it in annoying ways like ditching your partner in an Ethiopian airport.)
Being impatient is the best way to get faster at things. And across a surprising number of domains, being really fast correlates strongly with being effective.
Obviously, lots of these are non-causal correlations. Still, the sheer number of different datapoints is a surprising convergence:
E-MAIL
It seems trivial, but lots of different people have observed that being slow to respond to emails is a bad sign, or that famous people whom you'd expect to be swamped respond surprisingly quickly.
Sriram Krishnan:
Sam Altman:
STARTUPS
It's become common wisdom that launching (and iterating) quickly is a major factor behind whether startups succeed.
Sam Altman again:
This propagates even down to the level of how quickly you deploy software changes. Nick Schrock on Facebook / Instagram moving fast and breaking things:
It's not just Facebook; Accelerate found a strong correlation between deploy frequency and performance:
APPS/TOOLS
The "speed matters a lot" principle applies even to things that are already very fast. Google has found that users dramatically prefer faster webpages:
James Somers:
Nelson Elhage put it best:
PERSONAL WORKFLOW
Sam Altman:
Steve Yegge via Jeff Atwood:
This matches my experience at Wave, where the best engineers are disproportionately likely to type quickly, know their keyboard shortcuts, and have invested a lot of time making their common tasks efficient.
Obviously, those aren't the main things that make them good engineers—but I think they help in more than just the obvious ways.
NEGOTIATIONS
At Wave, when hiring, we've noticed that moving someone through the hiring process faster makes them much more likely to accept our offer. If we take a long time to get back to them or schedule the next steps, it both gives them more time to lose interest, and makes it seem like we're not excited about them. Not a good look!
This is apparently common trope in sales as well—"time kills all deals".
Paul Graham on how the founders of Stripe got time on their side:
Fred Wilson on the same effect in networking:
COMBAT
One of the most influential military strategy writers, John Boyd, is most famous for the idea of the "OODA loop:" that human action is an iterated process of observing the world, orienting within it, deciding how to respond and finally acting on the decision. Boyd's claim was that going through the OODA loop faster was a decisive advantage:
As a recent example, for instance, many states and countries waited far too long to lock down when the COVID epidemic hit because the virus got inside their OODA loop:
LIFE IN GENERAL
Patrick Collison:
(He also maintains a personal list of fast things.)
Sam Altman:
Why impatience?
There's an obvious way in which moving faster is important: if you're 10% more productive, you will finish your work in 10% less time, so you can do 10% more work total. But I don't think that's the main reason that speed is important.
It's worth pointing out at this point that all of the quotes above aren't just about churning out work—they're about processing information more quickly. The faster you process information, the faster you can incorporate the result into what you do next.
In other words, the main benefit of being fast is that you end up doing different things. Nelson Elhage's point—"having faster tools changes how users use a tool"—applies across nearly every domain:
If you respond to your emails quickly instead of slowly, you'll get access to more new opportunities, and end up prioritizing them over whatever you would have done instead.
If you make it 10x faster to test your code, you don't just save time waiting on tests—you can start doing test-driven development, discover your mistakes earlier, and save yourself from going down bad paths.
If you deploy your new app now instead of next week, you'll learn how users like the new features one week earlier, and you'll be able to feed that knowledge back into future product decisions.
That means that moving quickly is an advantage that compounds. Being twice as fast doesn't just double your output; it doubles the growth rate of your output. Over time, that makes an enormous difference.