You list many examples why it's good being fast. But who doubts that it is good being fast, smart, rich or healthy (ceteris paribus)? The critical point, given your motivating example and the title of the post, would be evidence for the sentence "Being impatient is the best way to get faster at things."
So, this is great for making one side of the case of what it is sometimes helpful to be impatient. But, feeling like if this were a schoolyard, and we were picking teams, and one team was Team Impatience, then Team Patience would definitely pick me, so I think I can say a few things about where we benefit from patience, lest we forget to reverse all advice and risk thinking impatience is better than it is due to selection biases.
Some things in favor of patience:
Further, as people age they seem to move from being less to more patient. I think there's a lot going on there, so it's hard to read too much into it, but it does suggest there is also virtue in patience, it just optimizes for different things.
Anway, none of this is to take away from your many great points about the value of impatience and the things it delivers, only to add some additional nuance I think this post leaves out in isolation.
Sounds like vaguely-good conclusions from my pattern-matching experience but very poorly argued, with much overloading of "impatience" and many cherry picked examples. Surprisingly bad quality from you. Also, "patience" is a great virtue, context matters a lot.
I haven’t read the whole post, but I agree with the message. Speed allows you to exploit opportunities before they disappear due to entropy. It keeps you motivated by making progress clear. It lets you try more things in a finite window of time. It can remove a bottleneck, unlocking abundance. Time is the one resource you can’t accumulate, except by speed ups. And speed allows highly competent individuals to avoid the slowdowns that come with having to coordinate groups.
I haven’t read the whole post, but I agree with the message.
Of course, if you agree with the message, you wouldn't read the whole post! :D
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 monstrous queue at passport control. As soon as I get my precious stamp, I sprint off to hold our place before more passengers get in front of us.
Ten minutes later, Eve finds me, groggy from our redeye and nonplussed about navigating Ethiopian visa controls 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 that they frequently did things in a sub-optimal order.)
Now that I’ve admitted it as a fault, I’m going to spend the rest of this post trying to convince you that being impatient is 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 in different domains is a mysterious-seeming convergence:
A seemingly trivial example, 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.
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”
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.
It’s become common wisdom that launching (and iterating) quickly is a major factor behind whether startups succeed.
[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:
46 times more frequent code deployments
440 times faster lead time from commit to deploy
The “speed matters a lot” principle applies even for things that are already very fast. Google has found that users dramatically prefer better 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.
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.
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.
I also made an effort to learn to type really fast and the keyboard shortcuts that help with my workflow.
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.
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.”
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.
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.)
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.
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. And that makes an enormous difference over time.